Create a Development Environment with Docker Compose by Mark Ranallo

it's been a long night and Ops is here to be the nightcap put everyone to sleep we've got a great talk on setting up a development environment with docker compose it's really just setting up anything with docker compose this doesn't really necessarily have to be a development environment this is just how to use docker compose to make something really so who hears actually use docker before alright who hears use docker compose a couple right so docker defined is a way of packaging your application into a standardized unit for software development that's one way they describe it another way is a doctrine container wrap a piece of wraps a piece of software and a complete file system along with all of the system tools the runtime the library everything else you would need to be installed on the server when you provision it and guarantees that software will be run consistently on different environments and different systems I like the second way of thinking about it because it's just easier it's more finite to to think of it as like it is all of the things you need put together and in a way that you can move it that's portable between environments so you know what is docker compose composes the way of running these like individual processes which you put in a docker container into multi container systems it's about arranging those containers like the different ways you'd you know the different pieces of your system are arranging them into a logical service which outlines all the dependencies that you would that need to be in existence and running and make sure they're booted and they're for when you go to use it so why would we use it I mean there's a lot of other things you could use instead like I use homebrew yes the answer is that works fine that works for some things but home brews best use cases if you're if you're working on kind of like the same if you're for your development environment if you're working on the same application daily and you deploy to any non docker production environment then that's probably going to be a path of least resistance for you because it's not involving a VM and there's there's complication and overhead but what if you but it also misses out on some key benefits that you would get like disposability and reusability but what if you're like what if you want the disposability reusability without darker like a regular VM or vagrant those will work but with the VM you lose the quick disposability of a docker container and with vagrant you get that back but you lose there's a lot of overhead to running multiple vagrant systems as anyone's done it if anyone has had a multi multi VM environment with vagrant and there's a lot of overhead so it comes down to that one question do you intend to use docker in production at some point or really value the disposability reusability if those if those questions are yes then I think it's that's the appropriate path to follow to try to set up an environment so let's let's look at what like a docker file looks like okay everyone see it all right so let's give we'll go back what I like about dr. files is very very simple to read and it reads really easy this is basically just saying it's using a public repo Ruby so it's saying like take a base image Ruby the version of at 2:33 and then run these following commands add a couple things change your working directory and then run another command you can almost you could provision a system then go back through your bash history and basically extract the parts you would need to write the docker file that's pretty nice why would I one good question asks is why would you split out all the individual installs there I mean you could just put that in one line well doctor does something clever and it caches the result of each line of a docker file so when you build this it's going to run and then cache the results of each line so if you change the last line it doesn't have to redo all the previous lines it just loads up the base image applies the new change and pass it down so that's how you can quickly iterate on the doctor file without rerunning the whole thing every single time it's it's really convenient so if we run that docker file we're used to using docker compose builds we'll see that later again but that's going to build that docker file and basically the first lines you see there are pulling the cash from the Ruby image so if the Ruby if the base image that you are changing changes you only pull the changes to that base image so you're not pull if the base images changes you're not pulling the whole thing every single time new it saves a lot of bandwidth and a lot of time it's really convenient and it's going to run through and you can see you can see the individual lines of like what it's doing each time it goes on forever so I just truncated it so what happens if we change the docker file and then rerun it well like zoom in on here you can see that there's the previous lines it just caches them so it just it takes no time at all it's just as using the cache using the cashews and the cache and then it gets to the line that we added and then applies that chain and then updates the container okay so we built one docker container this cap container happens to be a ruby container what you know now what what do we have we have just a one container that has Ruby let's try to do something with it so we're use docker compose we're going to use we're going to create a file called docker compose diamo and specify the API version we're using and then specify the service in this case the services web we're going to add our current directory because this file is just going to live in your rails app say this is a rails app it's going to live in the directory alongside your gem file and your any other blank files you have in there you're going to mount that directory inside the container and then run a command in this case bundle exec Puma which is going to boot the rails app there's two commands down at the bottom I kind of showed those just there's expose and ports expose basically that you don't need both of them I did it here for just just a show but expose will expose internally to docker a particular port so other containers can connect on that port and ports deals with what internal port in the container is exposed to the system so in this case I'm using 3000 3000 which just means that on I can connect from the local machine on 3000 and and it reach into the container on 3000 so we run this oops you know rails at with this is an error that just hood I kind of was torn on putting it on there because it gives me chills I can't connect also called my sequel server you see this not good like it especially in your production sort of system sorry Jeff yeah we need a DB so let's let's add let's let's actually use compose or you know compose a use docker compose to build the system so we're going to add another service this case we're going to add a database service we're just going to pull my sequel from the community my sequel and we are going to expose the port's 3 306 to ourselves so that you know this in this case it wouldn't matter if I took out that if I took out that 3 through the first 3 306 and ran a docker PS which just describes the running containers on the bottom there under ports there's 3 306 and then some long number 3 to 769 in this case that's what gets docker if you don't say expose this port to the local machine it's just going to pick a random port and it will change every time so so I set an environmental variable in this case just to allow the my sequel to not have a password and then the important thing there is the depends on DB which basically says this web service don't if someone if someone launches it or runs a command specifying it also launch the database because they can't run without the database that's kind of how you build a web of dependency and allows one-off commands to actually make sure everything is in a state needed to run let's say yeah we also though in order to get the thing running we have to make some changes to database dot yml this is not docker composed specific this is just rails but there's one important piece in here that I want that I want to show that kind of ties together some things about how you would build a system using docker compose and that is where it says host and it just says DB that's because the the instance or the service name for our database is DB and basically inside a container you can connect to any of the other containers through their service name so just by specifying the cert just by specifying dB it's going to through a DNS lookup know what the internal IP is for that docker and then connect and you don't have to worry about any of that you just have to know what the service name is so as you make those changes and then run one more command down there the bottom docker compose run I'll talk more about that command later it's going to go ahead and create the databases and then tada you will have a running rails app if you notice the one two seven zero zero one that's the IP connects to the docker machine on ok now that it's running let's like see some things that you would typically do every day if you were using a compose if you're using docker compose for your development environment build every time you change the doctor file that for either of your services you would run build which will just rebuild the docker file basically doctor compose RM this is removes a container it's like deleting this is what gives you the disposability like I'm just tossing a container and I'm going to recreate that something's weird with it I'm just going to you know doctor compose RM it up and down up boots everything so that's what you do when you first start anything up down is like running remove on everything it just deletes it delete your whole stack primarily you would use docker and compose start and stop so once you've up to everything you can just stop your stack if you're done with it and then start it back up again run run runs launches a container and then runs a command and then discards the container basically shuts it down so you would use this to just run a command basically and then exec is like run but it's slightly different in that it tries to attach to a running container and then executes inside of it so that's more for debugging you're trying to figure out the state everything is in you would use exec and logs is what you would do to get a nice - f to follow but logs would be a nice long list of everything that's going on on standard out inside your containers I've battled with composed a little bit so I have some tips from rural usage I'm going to save you hours right now hours don't put environmental can environment can specific config in the base image and try not to make environment specific images so the goal is to get the most out of it what you really want to do is have a single image that you can transport from development through to production through test through CI through all of that so try not to bake in specific things to the dog to the container itself you'll want to use environmental variables to set up the specific environment specific aspects of it its ties into mate like make sure individual containers are disposable well that sounds similar to I said but it's kind of different in that like this means just make sure that there's no state inside the container that will break things if it goes away so keep everything replaceable basically and utilize the community containers like the my sequel like the Ruby that I was just doing but feel comfortable creating your own if you want to use a specific container all the way through production this kind of you know you should feel comfortable enough to write your to make your own containers but feel free to use utilize the community once they're great and if your docker compose file is getting really complicated and long you can use something called expose or extends I'm sorry to break it up and basically what you would just do is like create two files and then create a new service that ends the other service like inheritance we just saw and then include both those files when you run the commands basically let's see all right so the big the big the big concern is if you're using docker for Mac be prepared for slow performance of a something called OS X FS which is included with docker for Mac and handles the native file like the native file system volume mounts so if you so earlier when we saw like if I were to specify a volume in a docker container OS X FS is that is the system in which those files are moved inside the container and if you use a lot of small files like Ruby gems or NPM it is maddeningly slow like it will make you angry lion how angry will it make you it'll make you uh let's say it'll make you angry enough to actually yearn for the for NFS which some people get it that's bad you know probably angry enough to hammer out an angry tweet on your Android phone at 3:00 a.m. like angry enough to port all glass of scotch and read a whole year long dialogue in this thread you can see there's it's the original bug report from the about OS x FS being slow and CPU bound and like the original date on it is March of 2016 so we're almost a year in and I don't know if any developers has ever indulged in reading the full extent of a year-long complaint thread it is is it it is a treat it's amazing that like towards the end of it people still thought there were things that hadn't been said at that point like my opinion on this must be heard sorry doctor I give up on you but there you know inside there there are pretty good write-ups on understanding the on from the docker employees on understanding what the problem is and steps they're going to take to fix it hasn't been fixed yet but that would be a big hang-up especially if you're using if you want to use docker compose for rails applications or like I said or like node you know NPM is going to take a long time to run bundle install is going to take a while etc their solution so you can you can use NFS you can switch the docker machine from the native one that comes with dot with docker for OS ten to something called dinghy which is just a replacement VM it supposedly has better performance you can use local drivers that's basically what that is it's like it's a it's a mount inside the container that it treats as native so it you don't sink there's no sink it just writes to it inside an example of using that would be if you see down at the bottom there I'd specify on my sequel data and then I mount that where the my sequel data would go basically if I if I go if I run a docker compose down and get rid of that entire stack that volume of data will still live on so you won't lose your you know your development environment data you won't lose your my sequel data and you can go you can spin the whole stack back up and everything will still be there that's a neat trick that would have saved me a lot of time another one is docker sink docker sink is something you can download from you see dr. sink that I oh it's a ruby gem basically it sets up a sinking container use this a tool called unison you know unison in is it's bi-directional sink so it things that change inside the container will sink to your to your machines file system and changes you make will sink inside the container and they'll have file events and stuff that's the big pain with like using NFS or any of those ones as they don't have like when you save a file inside the container it doesn't realize you save the file it knows the data changed but it doesn't know the file has changed itself that's why things like if you're enroute if you're in the Ruby environment like guard and stuff like that don't work but with this sync it does so it's kind of nice but it's one more thing you have to run on top but it's really fast so that was pretty dense I know it's tough to go last with with such a dense talk but hopefully there's enough value in there you can look through the the code samples and put together a quick environment especially if you're if you have small rails apps that you're spinning up that you want to go back to a good thing is if you ever have to go back to it like a year later you don't have to reset everything all up again you just run compose up it comes back if you've ever had to do that with like something you're working on homebrew you're like I don't even have the ruby version installed anymore to reinstall the ruby version reinstall the stuff so that's it hope you do it thank you I don't have questions but I'll take them in person afterwards it's worth long

Channel: Full Stack Talks

Views: 108,772

Keywords: iMovie

Id: Soh2k8lCXCA

Length: 21min 5sec (1265 seconds)

Published: Fri Feb 03 2017