So, the binary question comes into play in these discussions in odd ways. The idea with a docker container is you figure out how the upgrade for a db server or (more often) a set of libraries or security patches should work for your container's environment. Once. The container can be updated via the same steps live, if you so choose, or you can do a patch to the container image and send out the patch to all your other servers. This isn't unlike the bandwidth requirements for updating all servers anyway, but it is in an isolated environment, just like a VM would be.
This means there's some parallels for a VM setup, Vagrant or no. Vagrant, to my mind, was never meant for production, though, and people just started using it that way. One of the issues with Vagrant is it's a full machine. Are you really checking all the services that VM is running out of the box? Don't tell me you're using a minimalistic environment that runs busybox and has no daemons but your app. If you're using Vagrant, this may be possible, but it would be really hard. When IT upgrades some other services on the VM via Puppet or Salt or whatever, will it break your stuff? Who gets the call at 3 AM when they're doing that upgrade? Docker's advantages here are separation of concerns, compartmentalizing the needs of each area of responsibility. Otherwise it would just be a lighter-weight VM. I use it in my own case because even though I'm dev and IT and management, I can keep those functions from bleeding into each other and focus on them. At some point I'd like to have something deployed that has actual users, but for now I'm happy to use it in dev the way we are. I just can't go back to full environments after not having that headache for so long. On Mon, Aug 18, 2014 at 6:16 PM, Richard K Miller <[email protected]> wrote: > Yeah, I guess it just seems constraining to freeze binaries and > configuration into containers unless you're running at huge scale or need > extreme elasticity. For example, we only deploy a new db server, or > reinstall an old one, every 6-12 months. In that timeframe there are bound > to be MySQL security patches, rendering any container obsolete by the time > we would re-use it. Even for web servers, which are more numerous and more > elastic, we don't grow or shrink them often enough to need containers. And > then there's the question of whether to put application code in the > container! > > For us, although a Vagrant VM is "heavier", it's very easy to change or > rebuild because the configuration management is light-weight Puppet code. > We share Puppet code between development and production and rarely have > trouble with environments being out of sync. We've used Vagrant for 2 years > and are very happy with it. > > You could argue there are other reasons to use Docker, e.g. security. > > These are somewhat helpful: > > http://unix.stackexchange.com/questions/123482/application-updates-inside-of-docker-containers > > http://unix.stackexchange.com/questions/131009/when-and-why-should-i-use-apt-get-update > > After Dockercon, which I did not attend, I bookmarked a bunch of videos to > watch. There must be some reason this Docker craze is apparently sweeping > the nation. > https://www.youtube.com/playlist?list=PLkA60AVN3hh_CglPdPy3M_4yv_XEmXE10 > > Richard > > > > I'm using the term "production" here loosely, because we don't use docker > containers in production at work, and I don't do anything myself that could > be considered production. So with that caveat, let's discuss. > > Docker process is very flexible to be whatever you need it to be, so I can > only say how I use it, and how I think I'd like to use it, and they're > close enough right now I'll just give you one run-down: > > - Setup a docker file for the thing I wish to have encapsulated (usually a > single web service or database container) > - Create an image out of that docker file (for versioning later) so I will > never have to again (we share images from a single server in-house, so > every dev gets these revisions if the 'system' needs to change). > - Dev in our local repo, don't bother launching docker until you're ready > for testing against things > - Spin up a set of docker containers for any testing to run against for > the larger app (obviously you run your unit tests on their units somewhat > outside of these, but inside as well) > - Have jenkins or Travis do its own testing and packaging of docker images > - Deploy with a button! > > That's the dream anyway. I'm about half-way there with my own stuff, but > it's not very complex. Some of the things we've worked on are more modular > and have a dozen repos pulled into a single web app, and supporting > databas(es) in a separate container. You can separate things further and > have an nginx frontend divvy out things or what have you, and that can be > in its own container or just sitting there, and then you just spin up more > and more containers for scaling if needs be. Need more database nodes in > your cluster? Well, dockerize it and deploy it across a dozen environments > if you want, it doesn't matter, or you can just use Amazon instances, or > just hardware, or VPSes, etc. > > The point of docker is less about workflow and more about isolating > environments, so again, my thing is going to be my thing, but it shouldn't > dictate yours. The goal is that you will only have to figure out the > environment stuff once, and ship that as a whole. This fits with the > virtualbox methods but is more flexible in how you isolate things and much > more flexible with deployment options in mind. > > Your mileage may vary. Void where prohibited. Etc. > > -Tod Hansmann > Problem Solver > 801-735-1469 > > > On Mon, Aug 18, 2014 at 3:39 PM, Richard K Miller < > [email protected]> wrote: > >> Tod, are you using Docker in developer or production or both? I'm curious >> because I've mostly seen people speaking to Docker's virtues -- and it is >> very cool technology -- but I haven't seen a lot of people actually using >> it. >> >> (For those not familiar with Docker, it's a lightweight form of >> virtualization (kind of). It uses Linux LXC, which is similar to FreeBSD >> Jails, to keep applications and file systems separate from each other. >> Imagine having the MySQL binary and configuration running in their own >> layer. The root layer can see mysqld running. However, the MySQL layer can >> only see its own filesystem and processes. It's like having a server >> appliance inside a layer. Great encapsulation for convenience, security, >> etc.) >> >> Tod, I'm specifically curious how you do provisioning since neither >> Vagrant nor Docker do their own provisioning. >> >> Vagrant process: >> 1. Start with a base box, e.g. Ubuntu 14.04. >> 2. Write Puppet code to install MySQL >> 3. Distribute Vagrantfile to other developers >> 4. When other developers type "vagrant up", it downloads the base box, >> then Puppet installs MySQL >> 5. (Optional) If you decide that you always want MySQL on your VM, you >> can use a tool called Packer to create a new base box that includes MySQL. >> Then you don't need Puppet to install it each time. However, then you've >> frozen that MySQL binary and configuration into the box. If a MySQL upgrade >> comes along, you have to recreate the base box. At our company we do not do >> this step. >> >> Docker process: >> 1. Create a new Docker container >> 2. Install and configure MySQL manually (or maybe with Puppet?) >> 3. Save and distribute the Docker container to your developers, using it >> in both development and in production >> 4. If you need to make a change to MySQL, e.g. upgrade it, change >> configuration, etc. start back at step #1 >> >> Docker seems to be lighter for execution, but heavier for distribution >> since you're passing around containerized binaries. >> >> It seems perfect for letting someone try an open source project, e.g. >> "Click here to download the Postgresql/Redis/Riak Docker container and try >> it for yourself". Could also be an interesting way to distribute a >> proprietary server "appliance". >> >> FWIW, Vagrant now offers Docker support. It's considered a provisioner >> like Puppet or Chef. If you use run Vagrant+Docker on a Mac, it will >> transparently run a Linux VM since Mac doesn't support LXC natively. >> However, that still leaves me with the question, who/what does the manual >> work of installing and configuring MySQL? For us, the downsides of freezing >> the MySQL binary and configuration in a Docker container haven't been worth >> the Docker benefits. And for developers on Macs, it's one more layer they >> don't necessarily need. >> >> I'm really curious how you or anyone else is using it. >> >> Richard >> > >> > Alright, I'll be the unpopular one. >> > >> > I prefer docker for technical superiority (unless you're doing OS-level >> > dev, but this is UPHPU). I say this knowing it's linux-only. If >> that's a >> > problem, you're not imaginative enough for this conversation to be very >> > useful, since you can spinup a docker container and develop inside that >> > from any machine anywhere if you want to glue it together. If you're >> > programming in PHP, you're deploying to linux anyway. >> > >> > That's where docker gets really awesome. Not only is it WAY faster than >> > vagrant (by virtue of not having to provision an entire vm and >> environment) >> > it's also a deployable item. You can literally hand the app in a docker >> > container to IT or whatever and it will perform exactly as you expect it >> > to, because it's in the exact environment you meant it to be in, no >> > dependency or OS differences matter. >> > >> > It used to be a beta tool, but has recently been production ready and >> > useful. Vagrant is just a wrapper to virtualbox, and while I used it, >> it >> > seems like it was an inbetween help from the old ways of spinning up a >> vm >> > manually and the current joy of docker. >> > >> > Just do yourself a favor and learn the better tool. If you're on >> windows >> > or mac doing the development, well, figure out how to mount a linux >> > filesystem locally and just use a server for your docker provisioning or >> > something. Whatever works for you, I guess. Just don't limit yourself >> to >> > virtualbox for web dev. It's just going to continue to be a subpar >> method >> > of managing what is basically just in your way in the first place. >> > >> > So basically, go docker unless you need a windows/bsd/osx environment >> > (why?) for your site. >> > >> > >> > >> > _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
