Live data from Hacker News

What's new in Docker 1.13: prune, secrets, checkpoints and more

cloudshare.com

11–20 of 62 posts

Re: What's new in Docker 1.13: prune, secrets, checkpoints and more

#12

I'm just a guy that wants to deploy web apps. Is docker overkill for me? Basically, I want to be able to test something on my local machine under the same conditions it will be running on my server. Containerisation seems like the only way to do this that doesn't involve keeping packages and system configurations in sync in two or more systems.

> Containerisation seems like the only way to do this that doesn't involve keeping packages and system configurations in sync in two or more systems.

Virtual machines will also work.

Docker serves as a lightweight virtualization that will provide the same experience, assuming you are willing to keep to the kernel and Docker version "in sync" between prod and local.

Re: What's new in Docker 1.13: prune, secrets, checkpoints and more

#13

I'm just a guy that wants to deploy web apps. Is docker overkill for me? Basically, I want to be able to test something on my local machine under the same conditions it will be running on my server. Containerisation seems like the only way to do this that doesn't involve keeping packages and system configurations in sync in two or more systems.

My experience has been that it's great for local develoment, if your app is reasonably complex (ie Docker doesn't make sense if you only have an app worker and SQLite database), but I don't love it for production. In order for Docker to work well on production, you need something like Kubernetes, and that's a huge hassle for a small app.

I don't think that Kubernetes is the most important thing on prod. Some colleagues from another team at $WORK use plain Docker and "orchestrate" their containers with simple systemd units that run `docker stop|start`. If the app is only a single container, that should do it. (Actually, in that case, I think that `rkt run` would be better since the process runs below the same cgroup, and systemd can detect crashes and restart the container.)

Anyway, Kubernetes is not so important for small deployments, but what I've found really helpful is CoreOS: an auto-updating base OS that gets out of the way and (more importantly) ships a combination of Linux kernel + Docker that usually works really well.

Re: What's new in Docker 1.13: prune, secrets, checkpoints and more

#14
post #4

Looks like there's a mistake about image pruning: "Add -f to get rid of all unused images (ones with no containers running them)." But the option is actually `-a` -- `-f` just simply skips the prompt.

Like this? docker rmi -af I'm a bit confused by the backticks as I use them all the time scripting, but also in Markdown.

I have a gist for it: https://gist.github.com/pubkey/73dcb894cf5f7d262863

#stop and delete all containers

docker rm -f $(docker ps -a -q)

#delete all images

docker rmi -f $(docker images -q)

Re: What's new in Docker 1.13: prune, secrets, checkpoints and more

#15

Earlier quoted context omitted.

My experience has been that it's great for local develoment, if your app is reasonably complex (ie Docker doesn't make sense if you only have an app worker and SQLite database), but I don't love it for production. In order for Docker to work well on production, you need something like Kubernetes, and that's a huge hassle for a small app.

I don't think that Kubernetes is the most important thing on prod. Some colleagues from another team at $WORK use plain Docker and "orchestrate" their containers with simple systemd units that run `docker stop|start`. If the app is only a single container, that should do it. (Actually, in that case, I think that `rkt run` would be better since the process runs below the same cgroup, and systemd can detect crashes and…

What about docker-compose? We've recently started using it, and we don't see any problems; did your colleagues evaluate it?

Re: What's new in Docker 1.13: prune, secrets, checkpoints and more

#16

I'm just a guy that wants to deploy web apps. Is docker overkill for me? Basically, I want to be able to test something on my local machine under the same conditions it will be running on my server. Containerisation seems like the only way to do this that doesn't involve keeping packages and system configurations in sync in two or more systems.

You can try rkt[1] instead. Its from a container framework from coreos which makes a lot of things easier than docker.

Running it in a simple production setup is simply writing a systemd/initd job which starts the container. No container management daemon or orchestration framework involved.

[1] https://github.com/coreos/rkt

Re: What's new in Docker 1.13: prune, secrets, checkpoints and more

#17
post #15

Earlier quoted context omitted.

I don't think that Kubernetes is the most important thing on prod. Some colleagues from another team at $WORK use plain Docker and "orchestrate" their containers with simple systemd units that run `docker stop|start`. If the app is only a single container, that should do it. (Actually, in that case, I think that `rkt run` would be better since the process runs below the same cgroup, and systemd can detect crashes and…

What about docker-compose? We've recently started using it, and we don't see any problems; did your colleagues evaluate it?

docker-compose is really straightforward to get running, even moreso with docker-machine, and it gives you dev/prod parity, but the downside is that there's not a built in way to do zero downtime deploys.

Re: What's new in Docker 1.13: prune, secrets, checkpoints and more

#19

I'm just a guy that wants to deploy web apps. Is docker overkill for me? Basically, I want to be able to test something on my local machine under the same conditions it will be running on my server. Containerisation seems like the only way to do this that doesn't involve keeping packages and system configurations in sync in two or more systems.

For single-node applications, I develop on a LXC setup with a base template of the distribution that will run a production VM. This combination provides maximum dev/prod parity, the benefits of lightweight virtualization for development, and a boring, battle-tested production environment. The setup and deployment is written once for the choice distribution.

Re: What's new in Docker 1.13: prune, secrets, checkpoints and more

#20

Earlier quoted context omitted.

My experience has been that it's great for local develoment, if your app is reasonably complex (ie Docker doesn't make sense if you only have an app worker and SQLite database), but I don't love it for production. In order for Docker to work well on production, you need something like Kubernetes, and that's a huge hassle for a small app.

I don't think that Kubernetes is the most important thing on prod. Some colleagues from another team at $WORK use plain Docker and "orchestrate" their containers with simple systemd units that run `docker stop|start`. If the app is only a single container, that should do it. (Actually, in that case, I think that `rkt run` would be better since the process runs below the same cgroup, and systemd can detect crashes and…

Recent versions of systemd-nspawn can directly download a docker image and run it in a service unit.
Post reply on HN