We inherited some external projects at digEcor that did use it in production, and we had to stop that. For a while though, that was the way to get a production system out of that code monstrosity.
On Tue, Aug 19, 2014 at 8:33 AM, Richard K Miller <[email protected]> wrote: > 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
