Building a Local Dev Environment with Docker

several years ago karoku put out a methodology for building apps called the twelfth factor app I'm going to be putting out a series of videos on how to build a twelve factor Drupal app using docker with a brief demo to illustrate each point my name is Tom freed Hoff welcome to the first video of the series today I'll cover factor 1 one codebase many deploys and touch on factor 10 the dev prod parity concept I'll demo how to set up a Drupal development environment using docker docker sink and docker compose [Music] what's up the Internet let's talk a little bit about factor-1 it's actually kind of hard not to build the 12th back to wrap when using docker docker or containerization in general lends itself really well to the 12th doctor process factor one states one code base tracked in revision control many deploys in my opinion the number one reason for using docker is deployments specifically the parity of all the deployments of your own which is one part of factor 10 the dev prod parity concept typically when you hear the word deployment you think of dev stage or the pradhan Virant in some pot platform that you deploy to but as factor number one of the 12 factor app says a deploy is any running instance of the app every developer has a copy of the app running locally each of which also qualifies as a deploy the essence of this factor is that your app codebase should be kept in a cove repository like it and that every deploy or environment that runs your app pulls the code base from the same code repository so where does docker play into this docker is infrastructure right well if you've been following any of our blogs or our subscribe to our YouTube channel you know that we're huge proponents for infrastructure as code our view is that the infrastructure necessary to run an application as part of the application and should be in the same code repository as the application code base we've been doing this for years with vagrant and provisioners such as chef puppet and ansible and we've talked about it in our blog well with docker come on the scene our process has improved once again making packaging apps much easier to manage and share across separate deployments why is it a good idea to consider infrastructure as part of your application have you ever run into the situation with one of your co-workers or even worse with one of your clients saying well it works on my machine twelve factor calls this the tool yeah you can read more about that in factor 10 apps can behave differently on different technology stacks for example using engine X in production but developing on Apache locally or MySQL on production and SQLite locally you run the risk of bugs that only exist in one environment which are hard bugs to debug having all your deployment environments practically identical prevents these issues from happening I say practically because when your app is deployed to production the environment might be slightly different for example deploying to a cluster machines instead of a single machine these well it works on my machine issues can even happen across your team as well across your local environments developers using different operating systems locally create disparity developers on OS X may not have all the packages to run an app that exists on our developers machine using Linux and if you're on Windows good luck what do you do there I'll give you a hint install docker the disparity doesn't end with different technology platforms what about specific versions of technology for example running PHP 7.1 on production but your local environment is running PHP 5.6 in that scenario you'll most likely run into problems once you deploy to the production environment there are break and changes between those two versions of PHP that's why it's so important to package your infrastructure with your app so that your app can run with the smallest tools gap as possible between environments whether that be your individual developer machines or your dev stage and prod servers let's hop and do a demo I'm going to take you through setting up a local development environment with docker docker sink and docker compose we'll start to set up Drupal as a 12 factor app alright so let's go ahead and get our local environment set up if you want to follow along at home I've got this github repository it's a public repository you could find at this URL but this has basically got all of our doctor config to get a local environment set up locally so I'm going to clone the repository now this URL here and clone that out to my current directory all right so let's open up this codebase and see what we have we're going to go into the docker compose file first since that's where most of the magic is happening this docker compose file basically describes all the containers that we want to have in our app and so you can see right here we have a Maria DB container we have a PHP container I scroll down we have an engine X container and that's it we have three containers in the stock or compose file and specifically we're using images we don't have a docker file in our app yet we'll eventually put a docker file in there because we're going to customize some of these images but initially for this first video we're just going to pull the default images straight from docker hub so you can see we're pulling the Maria DB image directly from docker hub here and then the PHP container is actually using the Drupal image the 8.3 fpm image and if we scroll down engine acts is using the engine X latest image and so all these images are found on docker hub and so if we were to open up docker hub and type in Rupal you'll see the official Drupal images here and we're specifically pulling down 8.3 fpm so we're pulling down this version of the image from docker hub and so if you want to look at the details of what that includes you can go to their doctor file and see what exactly is being pulled in alright so we also have a docker compose dev file and this file is actually introduced because we're using a technology called docker sync and so if we do a quick google search for docker sync is a really cool library out there called docker sink that basically sets up sink containers so that you can have your code that's on your local machine actually run natively within a docker container and so docker sink is what does this magic we're specifically going to be using a sink strategy called native OS X and what's really cool about this docker sink process is that there's two way sync going on here we're essentially declaring to docker sync that everything in our source web profiles directory so if we open up this directory source web profile so essentially this active lamp profile here will be synced down to a docker container and now with docker compose we we can basically specify volumes to share within a specific container and so this docker compose dev file will basically define a volume on our PHP container saying use the Drupal sync container and mount the Drupal can sync container at this top inside of the PHP container and so this group will sync volume is actually created externally from docker compose it's created with this docker sync yamo file so this docker sync yamo file actually creates a new container inside of docker which just holds your sync files so when we end up starting our stack well what you'll see happen is a sync container will start and all the files from this directory will get synced into that container and then what will happen is our docker images will get downloaded and the containers will get started for that and this PHP container we're going to mount a volume which is that docker sync container here so our source web profiles directory will get actually mounted into the PHP container and so let me actually boot this up and show you how that works before I do I'm going to show you guys this make file all of our projects we have a it's common for us to put a make file in the root of the repository so that new developers that are coming on board can see the common commands that they need to run to actually set up the installation and so typically if we were actually doing a build with like a docker file typically you'd have to run this make setup build because what that will do is actually build the docker containers or build the docker images that we need for this application but for this particular application we don't have any docker files we're using the stock images that we're getting from docker hub so in this case we're just going to run make setup and what makes setup will do is it'll actually run a bundle install and bundle install is basically just running this command right here you'll see that we have docker sync specified in a jump file so basically docker sync will get installed when we run make setup and then if we had any images up on docker hub which we do we have the three images that we defined here the Morea DB the Drupal fpm and the engine X the pull images command will actually pull those images down so it's just running a docker compose pull here and then the last thing that we do is pull the pendency x' and I'm not going to cover that in this video but in a future video you'll see what pull dependencies actually does and so I'm going to run this command and start to set up this environment so you can see it's installing docker sync all of the Ruby dependencies to run docker sync and now it's pulling down the docker images from docker hub alright so now we have all the images from docker hub the the next command that we want to actually run is this make start command and so what makes start will do is this is going to start this stack and it'll essentially boot up all of the containers that we've defined in our docker compose it'll also read in this docker compose dev files so are our local containers will have this Drupal sink directory and it'll boot up this sink container as well that has all of our files in it so let's boot that up really quick and typically with these projects we have a readme file at the root of the project so that new developers see the commands that they need to execute to spin up these environments you can see here that it spun up several containers we have a PHP container that's one up there we have a Maria DB container you can actually see that it's gone up in inch and X container as well and right above that we have this sink log and this is where docker sink comes into play basically what happened is the files in the directory that we specified this source web files directory is going to get synced to a docker container and so let's let's take a look at all of that of the doctor containers that we currently have running and open up a new terminal here and run that docker PS and let's make this a little bit smaller so we can see this all in one line a little bit easier to read so you can see here that we have one two three four containers set up so we have the three containers that we defined in our docker compose file and then we have the one docker sink container down here let's not let's jump into the docker sink container that we named a purple sink and see what that looks like so I'm going to execute an interactive shell and run bash and so now I'm actually in this docker sink container if I LS this you're going to see that I have a directory called app sink and I have another directory called host sink now you can go read the docs our sink to see how this actually works but with the sink strategy that we're using we basically have mac OS writing to this host sink directory and then inside of the sink container there is a two way syncing technology called unison that's sinking from host to sink to app sink and app sink is what is actually mounted on the other containers that were adding the volume the docker sync volume to and so if I go into app sink and look at this you can see there's that active lamp directory that we are talking about and so let me just move over here you can see in the active lamp director we have config modules and this info file so let's LS that directory and sure enough we have the info file config and modules all right let's jump out of this container and look at our containers again we also have this engine X container here I'm going to jump into that in a second but before I do let me show you our docker compose file again for our inch and X container we mounted a couple volumes we mounted a Drupal install volume at var dub dub dub HTML and the reason why we mounted this Drupal install volume is because that Drupal install volume actually comes from this PHP container which is the Drupal docker image from docker hub and so by specifying a named volume we're able to share this volume from the PHP container with engine X so that when you visit VAR dub dub dub HTML on the nginx container it's actually going to hit the volume that's shared over on the PHP container one other thing you'll notice here is that we're taking this site.com file so if we open this this site.com file here we're moving into the comp d directory and naming it default comps and so essentially what we're doing is we're taking this configuration file and making that the default configuration of the nginx server before we jump into the engine X server you'll notice that we've configured this to work with Drupal essentially what we're saying is for every path basically look for the index dot PHP file in Drupal and task the URI as the Q parameter on the index dot PHP path and then we're also specifying that any files that have a PHP extension pass this off to the PHP container important ein thousand because this engine X server doesn't actually have PHP installed on it we're going to a separate container that does have PHP SPM installed and so engine acts is basically just passing off all that traffic to the PHP container this PHP alias right here coincides with the been names of our services and so if we named this group 'l then in our site back comm file we'd have to name this group as well and so these doc containers inside the docker host can talk to each other based off of these container alias names all right so let's jump in to the nginx container just to make sure that everything I said happened and so we're going to execute an interactive terminal and we're going to say I'm going to use the hash so six C seven three ash and so I'm going to go into the engine x container Tom's that D directory there's our default configuration if I kept that out to the terminal you'll see there's the file that we have in our local codebase all right the last thing that I want to do before we actually see this application working is I want to log in to the Drupal container and so this is again these containers are writing straight up images from docker hub and so you're going to see what docker hub basically gives us or what these images give us from docker hub so I'm going to go into this container here and so now I'm inside of the Drupal container and if ILS this you can see that we have a fresh install of Drupal 8 this was packaged inside of the docker image that we grabbed from docker hub one change that you will see in here is if I go into this profiles directory you'll see this active lamp directory and so again this is happening because we mounted the docker sync container to that path and so if I come over here to the docker compose dev directory you can see on the PHP container I'm mounting a volume called Drupal sink to this specific path within that container and again this Drupal sink is defined by this docker container mentioned in the docker sync file all right so let's hit this app in the browser as you can see on this engine X container I'm exposing port 70 80 and that's mapping to port 80 so let's hit 7080 in our browser this up and there you go we have this installation installer we're actually installing the active lamp profile and the reason why that is is if we open up our active lamp dot info file you can see that we named this as a distribution essentially copied the standard profile and then named it active lamp and called the disc called a distribution and Drupal is basically going to respect that and say we're installing the active lamp distribution so let's go ahead and run through this installer and we'll configure our site and there is our local installation of our active lamp profile now if we head over to the modules page I have a module in here called 12 sector and so you can see that it's automatically enabled because we mentioned that as a dependency of this profile so as you can see we have code on our local machine that's getting synced into a docker container and we're able to make modifications and see those changes in the docker container so if I go into this modules directory and let's add a module file here twelve factor module this will get automatically synced indoor docker container if we come over here we'll actually see it get synced over here and scroll down you can see that it actually synched that file over and if we jump into that docker container so let's I was already in that container let's go into profiles active lamp modules 12 factor and LS you can see there's our twelve factor module file in our docker container and if I were to there's no VI on here but if I echo some content into that I live world I've just added hello world into that module file inside of our container with the magic of dr. sync we should see that synchronization come synchronization come back up to our local machine and say there you see it hello world there and so this is one way of shipping your infrastructure with your actual application code now every developer that checks out this repository has an identical environment as the next developer and in a best-case scenario these docker containers are what you're actually deploying to production we're just barely scratching the surface with this twelve factor round to recap what I've shown you our application code is in the same repository as the infrastructure code to run this application as more dependencies on infrastructure become a requirement for example if we introduced a Redis cache we have an easy way to define that in our docker compose file and share that with all the other developers on this project by the way dependency management is actually the topic for our next video we'll talk more about that next time make sure you subscribe to our channel to get notified all of the individual deploys of this application not only have the same code base but also the same infrastructure that the app runs on all managed in revision control this approach truly fulfils factor one of the 12th actor app that's all I've got for you today if you liked this video make sure to give us a thumbs up and subscribe to our channel if you haven't already see you next time [Music] you

Channel: ActiveLAMP

Views: 121,561

Keywords: 12 Factor App, Twelve Factor App, Codebase, Dev/prod parity, Docker, Drupal, Drupal 7, Drupal 8, Vagrant, Ansible, Chef, Puppet Labs, 12 Factor Drupal App, Docker Sync, Docker Compose, Docker-Sync, Local Dev Environment

Id: FiaLKwdv9TI

Length: 23min 38sec (1418 seconds)

Published: Tue Aug 08 2017