11–20 of 30 posts
"# Docker hack to wait until Postgres is up, then run stuff." wat
docker-compose starts all services simultaneously and doesn't want you to use an init system inside the container, which means that any dependency that requires a service to be actually available needs some sort of waiting hack.
"# Docker hack to wait until Postgres is up, then run stuff." wat
This is unfortunately necessary. docker-compose starts all services simultaneously and doesn't want you to use an init system inside the container, which means that any dependency that requires a service to be actually available needs some sort of waiting hack.
From my experience "deploying" containers is pretty easy: build the image, push the image, pull the image, start container. The hard parts are: how to deal with persistency (I decided to let RDS manage my database), how to centralize logging and monitoring (just Cloudwatch? Swarm? Kubernetes?), how to make sure the cluster is healthy at all times (e.g. a container crashes, is it being replaced? How long does it take?) and how to make sure you have the correct number of containers running (e.g. I want 2 containers for the app server, 3 as workers, 1 as load-balancer).
If you really think about it, once you remove these advantages (from using containers, that is) the difference between running a container and having a script that provisions a virtualenv and adds a supervisor/systemd/initd service is negligible.
"# Docker hack to wait until Postgres is up, then run stuff." wat
This is unfortunately necessary. docker-compose starts all services simultaneously and doesn't want you to use an init system inside the container, which means that any dependency that requires a service to be actually available needs some sort of waiting hack.
Nice article but there is a fundamental thing missing: how to deploy and manage the fleet of containers to avoid downtime (e.g. having a systemd service that stops the container(s) and starts them with the new image is not optimal) and centralize logging. From my experience "deploying" containers is pretty easy: build the image, push the image, pull the image, start container. The hard parts are: how to deal with per…
If only it were easier to have seamless upgrades, it would be perfect.
Earlier quoted context omitted.
Hey slig. I use Git (or Github) flow, so yes, every commit to master is necessarily a deployment (that's why I only have the build and deployment running on the master branch). Captain Webhook just restarts the service. The systemd service file looks like this, and auto-pulls on every restart: https://www.pastery.net/xrutdm/ I will update the post with the above, thank you.
clone: https://www.pastery.net/yjqmbz/
Earlier quoted context omitted.
This is unfortunately necessary. docker-compose starts all services simultaneously and doesn't want you to use an init system inside the container, which means that any dependency that requires a service to be actually available needs some sort of waiting hack.
oh so there actually isn't a way to start the services in some sort of timed order? I've always wondered about that and I just have my services restart if they can't connect
I still prefer to use kubernetes for this: https://dewyatt.github.io/articles/continuous-deployment-of-...