Move an API Maker 3 Server to v4 in Place, with API Maker Launchpad

Intro

0:00 A server of API Maker 3, moved to version four in place, with API Maker Launchpad : checked before anything changes, every change shown first, the migration run on the server itself, and everything put back if anything fails.

An upgrade by hand

0:15 An upgrade by hand usually means stopping PM2 and hoping nothing else needed it, moving folders and editing the env file line by line, changing the Caddyfile without breaking the addresses of your apps, and no way back once the data has changed. With Launchpad, a check reads the server first, and changes nothing, a review shows every change before you confirm, the migration runs on the server, even with the app closed, and anything that fails puts everything back, data included.

0:46 In this video : a server of version three, and of four, the check, a server it refuses, where the server goes, the review, the run, a failure, rolled back, a migration cut by a reboot, and after the move.

Version three, version four

0:59 A server installed by the script of version three runs API Maker with PM2, or with systemd : two programs, api_maker_be and api_maker_fe, and the WebSockets on a port of their own. Caddy, started by hand, serves three addresses : the APIs, the WebSockets, and the files of the admin panel. MongoDB and Redis run in Docker, and the settings are in one env file. Version four is one program, run by systemd : the APIs and the WebSockets on one port, and the admin panel served by API Maker itself.

1:37 The same MongoDB and Redis, and Caddy keeps the addresses your apps use.

The check

1:42 Cloud mode, V3 to V4 Migration : check, choose, migrate, or roll back. acme-v3, the server of a customer, Acme, still on version three. Launchpad reads it, and changes nothing. Ready. PM2 runs version three : it stops, systemd runs version four, and PM2 keeps the other app it runs. MongoDB : three databases, forty one collections, saved before version four starts, and never changed. Caddy keeps the same addresses.

2:15 The license key stays the same, and the disk has room for the save. On the right, what version three runs, and the containers the migration never touches.

A server it refuses

2:25 Not every server can move. Here, the MongoDB of API Maker is on another server : acme-v3 is one server of several, and moving only this one would run versions three and four on the same database. Refused, with the reason. A Caddyfile it can not change, port forty six twenty six already used, too little disk, or a server Launchpad already manages : refused too, before anything changes.

Where it goes

2:53 Back to the server that can move. Where it goes in Launchpad : a new project, Acme, its environment production, and the latest version four. An environment that exists works too, when it has no server and was never deployed.

The review

3:08 What the migration does, step by step, and what happens when something fails : every change goes back, in the other order. The env file : every setting of version three kept, the secrets, MongoDB and Redis. Three lines added, for the admin panel and the Oracle client, and six commented out, each with its reason. The Caddyfile, before and after : the WebSockets go to the port of the APIs, and the admin panel to version four.

3:36 Seven checks at the end, the way apps reach the server. To start, type the name of the server.

The run

3:43 The migration runs on the server itself : closing the app, or losing the connection, does not stop it, and the app follows its log. First, with version three still running, version four is downloaded, checked against npm, and run once. Then version three stops, and MongoDB is saved while nothing writes to it. Version four takes its place under systemd, and Caddy now runs with systemd too. The checks pass, the way apps reach it.

4:11 Done : the server joins Acme, production.

When it fails

4:15 And when something fails? Here, version four does not answer when it starts. Everything goes back, in the other order : Caddy, the services, the data of MongoDB from its save, the env file, the folder of version three, and PM2. Version three answers again, as it ran before. The page of the server says the last migration was rolled back. A migration can also be cut on the server itself, by a reboot.

4:44 The page says where it stopped, and offers Roll back : from what the migration wrote down, version three comes back, as it ran.

After the move

4:54 After the move, the page of the server says where the folder of version three and the copies of before stay : delete them once you no longer need them. The environment works like any other : health, logs, files and terminals. Launchpad does not deploy it again : its MongoDB and Redis stay those of version three. What stays : the data, in the same containers of MongoDB and Redis, the secrets of the env file, the license key, the uploaded files, and the addresses of your apps, with their certificates.

5:28 What changes : systemd instead of PM2, one program instead of two, and the WebSockets on the port of the APIs : behind Caddy, their address does not change. Without Launchpad, the installer of video sixty one makes the same move, from the server itself.

Recap

5:46 To sum up. A check first, which changes nothing. A server it can not move is refused, with the reason. A review of every change, confirmed with the name of the server. The migration runs on the server, even with the app closed. And anything that fails puts everything back, data included. Next : day two of an environment in Launchpad. API Maker. Build faster, spend smarter, deliver better.