FWIW, I've never heard of anyone using Vagrant in production. We certainly don't. Puppet code is shared, but Vagrant is exclusively for development.
> 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 _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
