Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cloudshare.com

Post reply on HN
Print view View original

41–50 of 62 posts

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

#41

Post by johnbrodie »

lacampbell wrote: post #3

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.

I'll go against the grain here, and say that Vagrant + Ansible (or your favorite config management tool) will be easier to handle. It's well understood, simple, and you can try out any config changes in your local Vagrant environment before running the same changes on production.

At least in my mind, it's much more simple to say "OK, I installed these packages, let me add that to Ansible" than it is to get a production-ready Docker setup going.

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

#42

Post by andmarios »

joekrill wrote: post #29
andmarios wrote: post #26

Prune seems not that well thought to me. Don't get me wrong, I do find it useful but many people use containers as environments. Think about how many people are going to run prune only to find their work go missing. If you are gonna add a nuclear button, do it with a big red alert and give the option to whitelist some containers.

But that's really what `docker rm` is for, isn't it? I mean, if you want to only delete specific containers, use that. Prune has a specific purpose, which I think is very clear. If you're running the command, you (presumably) know what it should be doing. I suppose you could argue it might be nice to be able to do something like `docker container prune startsWith*` or something similar. But on the other hand, that fu…

But the thing people complain most isn't because they want to delete everything but because they need docker rm, xargs and complex bash foo to delete the containers and images they don't need.

For example I want to delete all old and all untagged versions of an image. I want to delete all stopped containers that use a specific image, or that were created more than two weeks ago. I want to delete all images starting with test.

Nuke everything? Not so much and to be honest this would be the easiest even with xargs and docker rm.

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

#43

Post by MrBuddyCasino »

scanr wrote: post #21
lacampbell wrote: post #3

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.

Docker may be overkill to start but it's relatively low cost to implement and it will definitely pay dividends over time: * You can be sure that what you're running locally is exactly what you'll be running on the server * Your deployment experience will be the same regardless of which tech stack you're using for the web application * There are many places you can deploy docker containers (Google GCE, Amazon ECS, Ama…

> it's relatively low cost to implement

Running Docker in production takes a huge amount of effort to get right and is not easily done.

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

#44

Post by mbreese »

dandermotj wrote: post #31

I'm really looking forward to seeing the scientific community adopt docker as a way to distribute reproducible research and coursework. MIT 6.S094 has a Dockerfile[^1] that contains all the software required for taking part in the class. This is a huge boon for getting stuck into the class and its coursework. [^1]: http://selfdrivingcars.mit.edu/files/Dockerfile

Most of the excitement that I've seen in the HPC scientific world has been around Singularity [1] containers. In particular, the main advantage seems to be keeping processes running as non-privileged users. This lets these containers get integrated with existing HPC clusters much easier.

[1] http://singularity.lbl.gov/

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

#45

Post by vkjv »

lojack wrote: post #39

Curious what methods others use for handling secrets at build time (using docker-compose). I'm currently installing (private) dependencies at runtime by mounting my secrets as a volume. I couldn't find a method that didn't seem to have some risk of inadvertently exposing them.

There are only methods that I'm aware of:

- Exposing the secrets on a (http) server that the Dockerfile can use to fetch

- What we use: Create a one time use secret that is destroyed after the image is built and before it is pushed.

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

#46

Post by cpuguy83 »

andmarios wrote: post #42
joekrill wrote: post #29

Earlier quoted context omitted.

But that's really what `docker rm` is for, isn't it? I mean, if you want to only delete specific containers, use that. Prune has a specific purpose, which I think is very clear. If you're running the command, you (presumably) know what it should be doing. I suppose you could argue it might be nice to be able to do something like `docker container prune startsWith*` or something similar. But on the other hand, that fu…

But the thing people complain most isn't because they want to delete everything but because they need docker rm, xargs and complex bash foo to delete the containers and images they don't need. For example I want to delete all old and all untagged versions of an image. I want to delete all stopped containers that use a specific image, or that were created more than two weeks ago. I want to delete all images starting w…

fyi, you do not need xargs.

`docker rm $(docker ps -q --filter blash)`

But agree, `prune` is currently sledge hammer and needs some refinement. It's not about not being well thought out, it's about getting something out there that can be built on top of.

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

#47

Post by cpuguy83 »

rockostrich wrote: post #30
tachion wrote: post #28

As much as I welcome the CLI cleanup, I can't stop thinking that the 'docker ps -> docker container ls' change makes no sense to anyone who has any experience with bsd/unix/linux systems. Seriously, why?

I agree. It looks like `docker ps` still works so it's nothing to really be concerned about just yet.

`docker ps` will never be removed.

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

#48

Post by nefasti »

scarlac wrote: post #8
lacampbell wrote: post #3

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.

Docker is very well suited for local development and testing, particularly since the launch of Docker for Mac and Windows. It makes utilities like MAMP less necessary. But apart from local development, I'd say that depends on your needs. If you want more ease-of-use, and you run a single-server hosting environment with multiple projects, it may be easier to keep doing that without adding Docker. But if you want incre…

Docker for local development for us been a pain in the butt. - We've hit performance problems with the filesystem, - Problem with caching things like yarn and npm install - The need to constantly rebuild the images for changes to be picked up. - Dificulty dealing with single docker file for prod and testing, making us want to montain 2 docker files.

Probably some bad setup of our part, but we've been using on production with kubernetes and none of those problems.

We're still using the compose to bootstrap database, caching, etc.

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

#49

Post by cpuguy83 »

lojack wrote: post #39

Curious what methods others use for handling secrets at build time (using docker-compose). I'm currently installing (private) dependencies at runtime by mounting my secrets as a volume. I couldn't find a method that didn't seem to have some risk of inadvertently exposing them.

Stay tuned for `docker build` support for secrets, and more secret backends in later versions.

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

#50

Post by StavrosK »

majewsky wrote: post #13
StavrosK wrote: post #10

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…

That's how I do deployments, but they take a while to start/stop. Whereas, with uwsgi, for example, deployments are zero-downtime, since uwsgi loads a new interpreter and uses that for new connections from that point on, without interrupting any old connections.
Post reply on HN