5 ms·
> Also, if you’re starting containers manually on the command line, you’re doing it wrong. At least use compose so your setup is declarative and lifetime-manage
by murkt 6y ago
> Also, if you’re starting containers manually on the command line, you’re doing it wrong. At least use compose so your setup is declarative and lifetime-managed.
As I wrote in a nearby comment, I'm not starting containers manually - we have compose, swarm, it's declarative and lifetime-managed.
However, we often need to do some bespoke data analysis, so we often ssh into a server, type `make shell` to launch a REPL and type/paste some stuff into it.
- akvadrako 6y agoYou can do all that with containers quickly. I develop my stuff with k8s with all it's lifetime management and have 10 second deploys from my dev box.
- murkt 6y ago10 seconds deploys? How is this possible :) Do you have any links that explain your workflow?
- akvadrako 6y agoIt's nothing fancy - I just use a typical k8s Service/Deployment object on GKE. A deploy is: 1. docker build (most layers cached) - 2s 2. docker push - 2s 3. update deploy.yaml 4. kubectl apply -f deploy.yaml 5. kubectl rollout status deployments {name} - 6s
- physicles 6y agoYeah this is exactly what I do too, works just fine. You probably already have something like this, but I hacked a bash+yq script that automatically updates all relevant yaml files with the latest image tag. So getting new code running is two lines: make image push deploy kubectl -f somewhere/deploy.yaml
- lovehashbrowns 6y agoLucky!! With our infrastructure, deploys can take an hour or so. 10 minutes for the build, 10 minutes for the image to get built, plus the rest of the time for terraform to apply infrastructure changes across dev, staging, and prod. Only thing we do have is automated testing after every deploy so issues tend to get caught. But that's still so long for a deploy! I don't know of a good way to get it down faster.
- jonfw 6y agoWhy is terraform deploying infrastructure for every container deployment? Can't you just rollout onto the existing infrastructure? Also sounds like there is some lay hanging fruit available by adding some caching/layering in the build process
- lovehashbrowns 6y agoAh, I should have explained more. That's an hour for our ASG + EC2 deployments. The only benefit we get is easy roll backs because it always deploys a new ASG. We're switching over to Spinnaker and started with our EC2 infrastructure. I think container deployments will be faster but still, an hour for EC2 deployments!
- shaklee3 6y agoTake a look at skaffold. Ours is under 10s
- tluyben2 6y agoStill 10 seconds. I have 0 seconds deploy for some ‘cowboy development’ I do; it is now a competitive advantage :) 10 sec (and for almost all setups I have seen it is vastly more that than) is a lot while devving and deploying for test. Each their own, but just fixing bugs live with my client (Zoom + me live on the test server fixing many issues in an afternoon) is vastly more efficient for me. Obviously committing from the test(now dev) server to github will result in ci/cd to the staging server, but workflows where I work on my local, commit, ci/cd to test and then the client tests is vastly slower and I do not like it; it feels like a waste of my time. In my main business I am forced (regulatory) to do it all by the book; vastly less enjoyable for me.