71–80 of 157 posts
I'm considering Docker for a small side project I have where I want to deploy a Runnable Java Jar as a daemon. Getting Java paths right across different Linux distributions can be a hassle, hoping Docker will help me solve this. For that matter, getting a daemon (service) running correctly on different Linux'es is one more thorn I'd rather not have to deal with.
I'm considering Docker for a small side project I have where I want to deploy a Runnable Java Jar as a daemon. Getting Java paths right across different Linux distributions can be a hassle, hoping Docker will help me solve this. For that matter, getting a daemon (service) running correctly on different Linux'es is one more thorn I'd rather not have to deal with.
And what do you mean about getting class paths right? Somehow I don't think best practice Java development necessarily calls for virtualization.
Earlier quoted context omitted.
I'm curious about a couple of things: - Are you/have you tried using "FROM" and layering things in multiple images to reduce what you need to keep shipping? - Anything stopping you from using a private registry? I'm running one at it seems to work quite well (with the caveat that it's annoying to have to specify the registry all the time). - You talk about "shuffling the data". Does that mean you're not using volumes…
1) We've talked about it but it's not a blocker so we haven't done it yet. Right now we're trying to reduce the number of layers we ship, since they seem to get big for no good reason. 2) We're using a private Docker Hub account to transfer images to the laptops. They have a script that the users can invoke that shuts down the container, updates, runs some initialization tasks (`db:migrate` + some other stuff) and th…
is completely dockerized, and rebuilds from scratch daily (phoenix deployment).
I've written a few blogs on this:
http://zwischenzugs.wordpress.com/2014/06/07/phoenix-deploym...
http://zwischenzugs.wordpress.com/2014/07/16/phoenix-deploym...
The tool I talk about there is here:
http://ianmiell.github.io/shutit/ https://github.com/ianmiell/shutit
I've also used Docker to provision AWS:
http://zwischenzugs.wordpress.com/2014/08/09/using-shutit-an...
http://zwischenzugs.wordpress.com/2014/09/15/using-shutit-an...
The system is composed of several components originally designed to run on separate VMs for security reasons. Luckily, we were able to translate VM docker container, so now each component has its own Dockerfile + shell script for booting up and providing runtime configuration.
Docker helps us solve several problems:
* A canonical build. It provides a way to configure the build system, fetch all dependencies and execute a reproducible build on different machines/environments. It's also used as documentation when engineers have no clue, where settings/parameters come from.
* A super fast build pipeline and release repository. We use maven -> nexus, docker -> docker-registry, vagrant -> local export for a completely automated way to bootstrap an ovf-file that can be deployed at customer site. Releases for the old platform were not automated and took the previous teams weeks (!) on a single platform.
* A way to restrict resources. Given some security constraints from the product, lxc + docker helps us restrict memory and networking.
* Shipping updates. We deliver automated updates through a hosted docker registry for customers who open up the appliance to the internet. Previous teams were not able deliver updates in time for a single hosted platform. We can now ship new releases and have them deployed at several customers data-centers in a matter of hours.
We have been using docker in production for almost a year now and despite headaches in the beginning it's been absolutely worth it.
- running graphite (can't say it was less pain launching it, since Dockerfile was outdated a bit, and I also had to additionally figure out persistency issues, but overall I'm happy it's all virtualized and not living on server itself)
- building our haskell projects for specific feature (your run a container per feature, this way you omit pain switching between features when you need to build one)
- running tests (per each feature we start container with whole infrastructure inside (all databases, projects etc.))
- running staging, also container per feature
Very useful stuff, comparing to alternatives, I should say. And quite easy to work with after you play a bit with docker's api.
We use docker for: - running graphite (can't say it was less pain launching it, since Dockerfile was outdated a bit, and I also had to additionally figure out persistency issues, but overall I'm happy it's all virtualized and not living on server itself) - building our haskell projects for specific feature (your run a container per feature, this way you omit pain switching between features when you need to build one)…
Here's the problems we're solving with Docker: * Sanity in our environments. We know exactly what goes into each and every environment, which are specialized based on the one-app-per-container principle. No more asking "why does software X build/execute on machine A and not machines B-C?" * Declarative deployments. Using Docker, Core OS, and fleet[1], this is the closest solution I've found to the dream of specifying…
With "git push aptible", we push the code to the production server, rebuild the project, and run it in one command.