Phusion Passenger Docker
github.com
github.com
However, there has to be something to manage the docker containers themselves - I imagine after 10 or so container sitting on a vm, it could get unruly to manage by hand.
Also, I've listened to speakers that mention long lasting services (like a database) should be handled differently in Dockerland - however, nobody I've listened to has spoken extensively about it.
A couple to start you off with are Fig[1] (acquired last year by Docker themselves) and Shipyard[2].
The fig.yml is controlled by salt to allow jinja scripting of variables like RAILS_ENV, databases, etc.
It works well. Clean separation of concerns between Vagrant (VM mgmt), Salt (provisioning and controller), and Docker (code) goes a long way towards a creating a pleasant DevOps experience.
In dev mode, we share local folders (./app) into the VM (/srv/app) and bind mount the VM folder into containers. In prod, we rsync code to the VM and bind mount into the containers.
For gems and other dependencies, we bundle them in the VM and bind mount them into Docker containers (non-trivial due to path issues) for both dev and prod. This flow makes it a lot more intuitive for devs who are used to running everything on their laptops. Code is still edited locally, but to update gems, a dev just runs `make bundle` instead of `bundle install` to trigger bundling in the VM.
We're planning on open sourcing parts of the system when we have a chance to finish the documentation. In the meantime, feel free to reach out if you want early access. Email on github[1].
https://github.com/nitrous-io/tug
https://www.digitalocean.com/community/tutorials/how-to-use-...
Amazon runs it's own variation of Linux which is different from the base image of this docker i.e. Ubuntu 14.04 LTS ?
This is thanks to Linux' relentless binary API backwards compatibility. The only thing your container interacts with is the kernel, and the API of the kernel never changes, so it'll run on any Linux operating system that's new enough to run Docker at all (and is 64-bit).
I'm sorry if I am completely missing the point of this effort.
I can appreciate the benefits of the underlying phusion-baseimage for addressing some common pitfalls and hurdles, but this layer on top takes things too far in my opinion. Ok, you have the option to customise it, but that comes across as an optional extra rather than an advised approach.
It provides the option to have memcached and Redis inside the container, but it is optional and not installed by default. You have to explicitly enable them.
Passenger-docker only handles a single role: the app. Depending on your viewpoint, caching may or may not be considered to be a logical part of the app. This is why we provide the option. But again, disabled by default because we go for lightweight by default.
I take your point that there may be situations where it's pragmatic to have memcached/Redis in the same container as your app, and that they are disabled by default, but I still feel the balance of the README is wrong as it doesn't sound any kind of warning that you probably don't want to do that in most cases.
I'd suggest the README could be improved to better communicate the intended use cases of the images.
But they're not all included in the same image. We have 8 variants, 6 of which only contain a single language. There is 1 which contains everything, and there's 1 which contains nothing and is meant for customization.
> web server, app server
The web server and the app server are the same thing. Passenger is an Nginx module.
> aux services and tools.
Only the minimum possible to allow regular administration, inspection and debugging.
> First impressions are that this image is one-size-fits-all
But it is not. That's why we have 8 variants. Early in development we've explicitly made this a many-sizes-fit-all thing.
> and that they are disabled by default, but I still feel the balance of the README is wrong as it doesn't sound any kind of warning that you probably don't want to do that in most cases.
Fair enough, though I disagree. I'd rather assume the user knows what he's doing. If he chose to enable Redis then there's probably a good reason for that.
I'm explaining the impression that it gives, rightly or wrongly, to those not as intimately familiar with it as you; those less familiar with Docker who may read through the README and come away thinking that it's ok to mix roles without appreciating the unwritten use cases you actually had in mind; those newer to Docker who have a Node app and a Ruby app and think "hey, this passenger-full image looks convenient, I'll use that" without appreciating the implications.
> It's even better than that: Redis and Memcached aren't even INSTALLED by default. Thus, no warning is needed. If you don't explicitly choose to use them, you do not pay any price.
Doesn't say that in the README, just says they're disabled. The fact they're not installed doesn't impact on the impression that's given.
* Ruby: https://registry.hub.docker.com/_/ruby/
* Python: https://registry.hub.docker.com/_/python/
* Node: https://registry.hub.docker.com/_/node/
* Meteor: https://registry.hub.docker.com/u/danieldent/meteor/
And the other dependencies (i.e. database) have Docker images of their own that you can use.
Nice and composable, reproducible infrastructure.
This phusion-passenger-all-in-one monstrosity puts us back in the pre-Docker days.
Packaging your application in a 'light-weight' way is not one of the big benefits of Docker. Packaging your application in an isolated environment is _the_ big benefit of Docker, and that's exactly the benefit you get with this image.
There's nothing monstrous about this image. It's based on the official Ubuntu image, has a few extra packages installed to satisfy some more dependencies so it's easier to use for other users, and Passenger itself is just a few MB.
You probably don't get Docker very well. The idea is that you start a Docker container, and after a while a service is online on the port you EXPOSE-d. If a container satisfies those properties, then it's as composable and reproducible as any other. It's the magic of Docker.
You talked about “an entire init system”, but this init system is a lightweight, stripped down variant written especially for Docker. The entire thing is just a few hundred lines Python script. You may be thinking that an init system is not necessary in Docker, but that is not true, as I’ve explained in “Docker and the PID 1 zombie reaping problem”: http://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombi...
With passenger-docker, you only create an image with your web app in it, plus an app server to run that web app. Nothing more. The database is still external. Memcached and Redis are not installed unless you explicitly enable them. The image is lightweight as you can expect from Ruby, Python and Node.js apps.
In fact, we've explicitly split the image 8 variants, each variant containing only the minimum possible: https://github.com/phusion/passenger-docker#image_variants
Passenger-docker is very much in line with the idea of composable, reproducible infrastructure. Nothing in passenger-docker violates those principles.
I just wanted to thank you for all your hard work and for putting this out there for people to get up and running with Docker.
Of the videos I've watched on deploying Ruby on Rails apps with Docker, this container always gets a shoutout as an easy way to get started.
While this isn't true (as explained by others), I don't know why there's such dismissal in the docker community for a VM with ~zero boot time, good tools without requiring ssh (`docker cp`, `docker diff`, `docker exec`, volumes) and layers. These are good things! Of course packaging in a light-weight way is nice if you can manage that as well but it's not everything.
> Nice and composable, reproducible infrastructure.
Phusion passenger is also reproducible you're still using (the highly touted) Dockerfiles. I've no idea how you want to define composability.