3 ms·
We've experimented with docker in a few places, and the deployment workflow is just painful: 1. sudo docker build -t quay.io/foo/bar 2. sudo docker push qu
by daxorid 10y ago
We've experimented with docker in a few places, and the deployment workflow is just painful:
1. sudo docker build -t quay.io/foo/bar
2. sudo docker push quay.io/foo/bar
3. <login to production>
4. sudo docker pull quay.io/foo/bar
5. sudo docker kill foobar
6. sudo docker rm foobar
7. sudo docker run -p 80:80 -p 443:443 -e FOO=bar --name foobar --net=host -d quay.io/foo/bar
I can never understand how people talk about docker making deployments somehow easier.
- kinghajj 10y agoElasticBeanstalk streamlines things greatly, and when it works everything is pretty nice. When it fails, though... for instance, just a few days ago, one of the containers failed with an OOM error. For some reason--still unclear--the ECS and/or Docker daemons weren't able to start new containers to replace them, leaving the instance broken for hours. Auto-scaling groups will mitigate this, but it's still unnerving. Still, I'm liking many aspects our tools. Using Docker with Rocker (https://github.com/grammarly/rocker/ https://github.com/grammarly/rocker/) has greatly sped-up CI builds by caching results when the source hasn't changed (especially important in multi-language shops; the Python guys don't want to wait on the Java code to build every time.) Just upload a tagged image to ECR, generate an "application version" referencing those images, and deploy via the Slack bot ("@bula deploy develop develop-XXX-e83fc3bd").
- justinsaccount 10y agoHow is that painful? I run a service using docker and have your steps 4 through 7 as part of a systemd unit file. Updating the application requires a single systemd restart command.
- sandGorgon 10y agocould you talk about your deployment scripts ? i am trying to deploy a single flask app which uses redis. I'm not sure how to set up logging, etc. and whether redis and flask will go in the same VM.
- justinsaccount 10y agoNot much in the way of scripts, but the systemd file I use is something like this: [Unit] Description=App After=docker.service Requires=docker.service [Service] TimeoutStartSec=0 ExecStartPre=/usr/bin/docker pull app ExecStartPre=-/usr/bin/docker kill app ExecStartPre=-/usr/bin/docker rm app ExecStart=/usr/bin/docker run --name app --rm=true -p 80:80 app [Install] WantedBy=multi-user.target With something like dokku I could just push the git repo containing the Dockerfile and it would accomplish the same thing
- detiber 10y agoYou probably also want to add: PartOf=Docker.service This will ensure that a restart of the docker service will trigger this service to be restarted.
- dexterbt1 10y agoFor us: Jenkins do steps 1 and 2. Steps 3-7 is simply "push button" via ansible.
- benjaminwootton 10y agoBring back the 10,000 line bash scripts, Puppet, configuration drift, inconsistent environments. All is forgiven!
- majewsky 10y agoReplace 4 to 7 with a single "kubectl rolling-update".
- gaius 10y agoIf your Unix user is in the docker group, no need to sudo.
- lobster_johnson 10y agoIf you're using Kubernetes, steps 3-7 and replaced with a single "kubectl" line, and you can even eliminate that by baking it into your Quay setup. (Why would you ever do step 1-2, though? Quay supports Github hooks.) We've started using a self-hosted Drone [1] install (not to be confused with the hosted drone.io service, which is not good) to build containers. Unlike Quay, it doesn't launch build VMs, but rather uses Docker containers, so it's very fast. It also supports the notion of build containers, so you can do things like compile C code or run NPM without ending up with any compilers or build tools in any of your image layers; it completely removes the need for a custom "base image" shared among apps. It also lets us add the Kubernetes deploy as a final step after publishing. [1] http://readme.drone.io/ http://readme.drone.io/