7 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
christianmanivong	0effa93895	Merge pull request 'fix: remove the bundled registry from every host, and stop starting it' (#5) from fix/retire-registry into main	2026-10-07 14:19:28 +00:00
Christian Manivong	de46ab8a0f	fix: remove the bundled registry from every host, and stop starting it ... netOrk's docker-compose.yml shipped a registry:2 for the satellite image, and this script started it on every deploy as infrastructure. Satellites pull from registry.netork.io; on 172.22.8.50 the registry held one old image, nothing had pulled from it in 30 days, and it accepted anonymous pushes on port 5000 of every instance (NetOrk/netork#763). - registry leaves INFRA_SERVICES. - A new step removes services netOrk no longer ships: the container netork-registry-1, then the volume netork_registry_data. `docker compose up` never removes a container whose service left the compose file, so without this each host would keep it until someone removed it by hand. The step is idempotent and works with the old compose file as well as the new one, so it can go out before netOrk drops the service.	2026-10-07 16:17:23 +02:00
christianmanivong	9a93897cd2	Merge pull request 'fix: one deploy per host at a time, under a lock the host frees on its own' (#4) from fix/host-deploy-lock into main	2026-10-07 04:43:24 +00:00
Christian Manivong	ec93619f8f	fix: one deploy per host at a time, under a lock the host frees on its own ... Several sessions deploy to the same test server, and two runs used to overlap. On 2026-10-05 two `up -d --force-recreate` runs recreated each other's containers and the API was down for a minute (#1). On 2026-10-06 two runs renamed each other's *.new compose files and one broke off; with two different tags, one tag's compose files could have started the other's images (#3). - Each deploy first takes flock on ~/netork/.deploy.lock on the host. An ssh session holds it: the remote side takes the lock on fd 9, reports LOCKED and waits on its stdin, so ending the session frees it, whether the deploy finished, failed, was interrupted or lost its connection. Checked over real ssh on .50, including a client killed with -9. - A second deploy prints who holds the lock, since when and with which tag, and waits up to DEPLOY_LOCK_WAIT seconds (default 900); then it gives up without touching the host. - A host without flock is deployed without the lock, with a warning. - deploy_server is now the lock around deploy_steps, the old body. Closes #1 Closes #3	2026-10-07 06:42:13 +02:00
christianmanivong	6444aa97f3	Merge pull request 'fix: a failed container recreate is tried once more before the deploy gives up' (#2) from fix/recreate-retry into main	2026-10-05 20:03:55 +00:00
Christian Manivong	923ec4ce65	fix: a failed container recreate is tried once more before the deploy gives up ... On 2026-10-05 a deploy to 172.22.8.50 failed in "Starting containers": docker compose up -d --force-recreate recreates the services in parallel, lost a container it had just renamed ("No such container: 02586df7…") and stopped with every engine container Created and none running. The old API was already gone, so netOrk was down for about two minutes, until the same deploy was run again and went through cleanly. The script now does that second run itself, after DEPLOY_RECREATE_RETRY_DELAY seconds (5 by default). If the second attempt fails too, it prints the container states (docker compose ps -a) and fails as before. Tests run the script against a fake ssh that fails the recreate zero, one or two times. README step 3 says what happens. Refs NetOrk/netork#586	2026-10-05 21:58:36 +02:00
Christian Manivong	a928d5eec3	Initial import of the netOrk deploy script	2026-09-28 19:55:22 +02:00