What's new in Docker 1.13: prune, secrets, checkpoints and more
1–10 of 62 posts
Re: What's new in Docker 1.13: prune, secrets, checkpoints and more
#2Secrets is a big one! Will really help speed up enterprise adoption.
Re: What's new in Docker 1.13: prune, secrets, checkpoints and more
#3I'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.
Re: What's new in Docker 1.13: prune, secrets, checkpoints and more
#4Looks 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.
Re: What's new in Docker 1.13: prune, secrets, checkpoints and more
#5[deleted]
Re: What's new in Docker 1.13: prune, secrets, checkpoints and more
#6I'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.
In a nutshell, this is why I'm now hooked on docker. I can reproducibly build things on my macbook without tearing up the system packages, and I can deploy them to my small datacenter without thinking twice.
I'd suggest you at least try it out.
Re: What's new in Docker 1.13: prune, secrets, checkpoints and more
#7I'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.
Does your web app have a database?
Re: What's new in Docker 1.13: prune, secrets, checkpoints and more
#8I'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 increased security and better isolation between your projects, Docker is likely a better solution.
In any case, I would strongly recommend that you familiarize yourself with Docker, at least locally. After a while, you can decide if you want to take the leap and use it on your server as well.
Re: What's new in Docker 1.13: prune, secrets, checkpoints and more
#9Looks 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.
Re: What's new in Docker 1.13: prune, secrets, checkpoints and more
#10I'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.