Yes, I suppose there could be a Puppet/Chef/Salt repo that creates the Docker container, and then a separate repo for the Docker container itself. You would distribute the 2nd repo but not the 1st, I would think. I don't know enough about Docker to know what common practice is, but maintaining Docker containers sounds to me like a pain in the neck for most use cases.
> That's a good question. Could you store the Docker setup in a git repo like > you can with the lightweight Vagrant scripts? > > -Sean Thayne > > > 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. > > > > > > On Fri, Aug 15, 2014 at 1:11 PM, Matt Gauthier <[email protected]> wrote: > > > >> Once you go Vagrant, you never go back.... > >> > >> > >> On Fri, Aug 15, 2014 at 11:16 AM, James Guymon <[email protected]> > >> wrote: > >> > >>> Another up-vote from a vagrant user here. > >>> > >>> -----Original Message----- > >>> From: [email protected] [mailto:[email protected]] On Behalf > >>> Of Sean Thayne > >>> Sent: Friday, August 15, 2014 11:05 AM > >>> To: Tim Harper > >>> Cc: uphpu > >>> Subject: Re: [UPHPU] Vagrant (up or down) > >>> > >>> Yo Jim! > >>> > >>> Vagrant is amazing. For a quick test drive, you should check out > >>> www.puphpet.com for a quick setup. It's really easy to customize after > >>> the fact as well. So with Playground's stuff, we have it so you can just > >>> run `vagrant up` and it does everything, configures apache, creates local > >>> db, propagates it, etc. It's really slick. We store the vagrant files in > >>> the git repo with the source code, so it's just a git clone and vagrant > >> up, > >>> and your ready to code. > >>> > >>> Also a side note, it uses shared folders, so you can use whatever mac > >>> editor or pc editor you want, and code edits are fast. It also allows > >> your > >>> editor to be able to index all your code fast, because it's all still > >> local. > >>> > >>> Best setup I've ever used > >>> > >>> -Sean Thayne > >>> > >>> > >>> On Fri, Aug 15, 2014 at 10:55 AM, Tim Harper <[email protected]> > >> wrote: > >>> > >>>> This depends on your environment. You may be able to find a pre-built > >>>> image with your stack all ready to go, and that'd be the simplest. > >>>> > >>>> The more custom your setup, the more complex it gets. > >>>> > >>>> Vagrant allows you to create a provisioning script to further > >>>> configure the instance after spinning it up. It also has tools > >>>> integration with tools like Puppet or SaltStack, which are great if > >>>> you want to keep dev environment in sync with test / production > >>> environments. > >>>> > >>>> On Aug 15, 2014, at 10:30, thin <[email protected]> wrote: > >>>> > >>>>> Vagrant seems like a universal thumbs up then. Cool. Can any of you > >>>>> speak to what the ramp up / setup effort might be? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Aug 15, 2014 at 10:06 AM, David Skinner < > >>>> [email protected]> > >>>>> wrote: > >>>>> > >>>>>> We also use Vagrant everyday here where I work. For the same > >>>>>> reasons Richard Miller gave. We do have a different configuration > >>>>>> though. Our project has many domains pointed to our code base. Our > >>>>>> provisioning > >>>> sets up > >>>>>> each project with a specific private IP address. 10.0.0.2. We then > >>>>>> use dnsmasq and configure a custom TLD to point to the vagrant > >>>>>> machine. The dnsmasq config uses a wildcard to route all traffic on > >>>>>> our local machine using the custom TLD to the IP address of our > >>>>>> vagrant machine. Our TLD > >>>> is > >>>>>> ".sc". So I can simply type something like clientdomain.com.sc in > >>>>>> my browser and dnsmasq will route it to my vagrant box, loading the > >>>>>> clients version of our site. This helps us as we bring on new > >>>>>> clients all the > >>>> time > >>>>>> using their own domain. We have a table in the database that stores > >>>>>> the clients info along with their domain name. We then refer to > >>>>>> that table > >>>> with > >>>>>> a provisioning script to dynamically generate the Apache configs > >>>>>> for the vagrant environment, automatically appending the .sc TLD. > >>>>>> > >>>>>> Before we use Vagrant, it could take a person 1 - 3 days to get > >>>>>> their environment set up correctly. Now with Vagrant, we can have > >>>>>> someone up > >>>> and > >>>>>> running in about an hour. You can also use Vagrant to provision EC2 > >>>>>> instances on Amazon if that's something that would be helpful. > >>>>>> > >>>>>> Another use case where Vagrant came in super helpful was a PHP > >>>>>> version upgrade. We simply cloned a new copy of our project. Made > >>>>>> an upgrade branch. Changed the provision scripts to install a newer > >>> version of PHP. > >>>>>> Pushed the branch up to origin. Then each developer could clone the > >>>>>> project, switch to that branch, then run vagrant up to provision > >>>>>> that environment with the new version of PHP. Then we all worked > >>>>>> together to make the code compatible with the newer version of PHP. > >>>>>> Since we had > >>>> this > >>>>>> second clone of the codebase, we could easily turn of the newer > >>>>>> machine > >>>> and > >>>>>> turn on the old one to perform any emergency bug fixes that were > >>>>>> needed > >>>> on > >>>>>> the Production servers. > >>>>>> > >>>>>> We use Debian 7 as a base. > >>>>>> We use a collection of shell scripts to provision the environment. > >>>> Though > >>>>>> when time permits we'd like to move to something better like Puppet. > >>>>>> > >>>>>> dnsmasq: http://www.thekelleys.org.uk/dnsmasq/doc.html > >>>>>> AWS EC2 integration: https://github.com/mitchellh/vagrant-aws > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> > >>>>> 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 > >>>> > >>> > >>> _______________________________________________ > >>> > >>> 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 > >>> > >> > >> _______________________________________________ > >> > >> 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 > > > > > _______________________________________________ > > 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
