 So, this is the time in the schedule where you go to the sleeper sessions because we've just had lunch and we're all ready to get comfortable and take a nap, right? So, hopefully, I'll keep your attention as best as I can. All right, yeah, welcome to the session on Docker Power Team and Deployment. My name is David Newman. There's a link to my GitHub page which is actually just a link to these slides. So, if you want them, if you want to grab these slides later or whatever, I will also post these slides in the session on the conference website. Just briefly about myself. On Drupal, my username is Dave N. Yeah, I've been working with Drupal, I think, for about seven years. And I've been working at Civic Actions for around four years. Drupal developer, Sis Admin. Just want to also mention Civic Actions. I know we shouldn't do too much, you know, self-promoting of our companies. But I want to make a claim that I think Civic Actions has the highest average height for any Drupal company. If you take the averages over height, there's a lot of us over six feet. So, anyone is welcome to challenge that, but I think we might be among the tallest Drupal companies. So, something to consider. And, yeah, we're in the DevOps track here. I think DevOps, I started becoming interested in that subject about a year and a half ago. Really, Drupal plus DevOps really got into it more at DrupalCon Amsterdam, which is that. Really great sessions there as well. So, I just thought, can everybody hear me okay? Am I in the back? Everybody thumbs up? Thank you very much. So, yeah, DevOps track, welcome. There's a lot of good looking sessions in this, so please enjoy. And this session I'm going to be talking about Docker and how to use Docker for your development team, so your developer sandboxes. And I'm also going to try to describe how to use it in deployment as best as we can. And, yeah, I'll have the time for questions afterwards. So, sandboxes. This is a picture of my daughter's sandbox. She's two years old. And what makes up a sandbox for a developer? Not these tools, but basically when a developer starts on a project for your company, doing a Drupal project, they need the code, the Git repository. They need a snapshot of a database. And then, you know, the actual running services, be it Apache or Nginx or the database running itself, of course. And then there's also developer tools, SaaS, Compass, code sniffer, those kinds of things. So, there's a lot of different components. And actually, this is a growing set because we keep coming out with new and exciting things, right? Like, in Dree's keynote, he's talking about the front end. I'm not a front-end guy, so I'm really not up on that, but angular backbone. So, there's a whole slew of different things. And, yeah, so, typical team, you have to really think about how are developers using all these tools together. And, yeah, what does it look like on your developer's machine? Here's my daughter playing outside of her sandbox. Who here actually supports your team in their developer sandbox? Like, they have problems setting up, ramping up into the project. Yeah, so about a third of you. Yeah, I do that as well. And it's hard to do because you just never know how they're going to use it or how it might change. So, I think this image is interesting because she's, like, not playing with a sandbox. She's playing with water in a broom outside of the sandbox. So, you never know how messy it might become. And sandboxes are really messy. Who has kids? Sandboxes are messy. It gets everywhere. Anyway, so, that's sort of what I'm starting with is talking about sandboxes. Docker came along about a couple of years ago. It's a really active community. I did a tweet with the hashtag Docker and I got, like, 1400 retweets. No, not, sorry, 1400 impressions. But it's a very active community. There's a lot of people on Twitter and, of course, there's Docker conferences and everything. So, what is Docker? This is my description of it. It's probably broader than this, but it's an elegant new cross-platform development and deployment tool. If you go to the website, the website's really great too. Actually, check it out. Great documentation and good intro to Docker itself. But they talk about build, ship, run. And what they're describing there is basically a common experience for your development and deployment. That's, in my mind, that's an underlying goal of what Docker is, so that your development team is essentially using the same stack, the same tool as what's ending up on production. And the primary metaphor, the primary image for Docker is a shipping container, which I think is a great analogy. And I don't want to go too far into that, but... Actually, that'll come up later as I describe other things, but... So, in a sense, Docker is virtualization. It's very similar to a virtual machine, like VirtualBox. How many people use Vagrant? Wow, like everybody. So, yeah, it's a tool very much like Vagrant. This diagram shows... This makes it pretty clear for me anyway. The left side shows kind of how Vagrant will work with VirtualBox or whatever the virtualization tool is. The underlying infrastructure, the hardware, and the operating system, are similar on both of those. And then with a virtual machine set up, you also need the hypervisor. And then the guest OS, so if you're running, in this example, three different applications, each one of those applications need the entire guest operating system, including the kernel and all of the running things. Yeah, then the libraries and everything, your application would be on top of that. So, if you had just an example, if you had two Drupal projects on the go, you could have two virtual machines running with entire stacks like that. Docker, on the right side, is way more efficient. It actually reuses the running kernel. The running Linux kernel of the host is reused. I don't know if I'm explaining that well, but it's much more lightweight. Basically, you just run your supporting libraries or whatever in your application within a container. What that allows you to do is, because it's so lightweight, you can actually have a whole bunch of containers, potentially hundreds of containers on the same host. And if you are just running similar things, especially, it's more efficient to do sort of repeated images of a container. Docker, actually I should also ask, how many people are familiar with Docker at all? Okay, a lot of you. How many have used Docker? More than half. Okay, I'll try to go quicker through the Docker intro, because I think you probably already know a lot of these things. So, there's the Docker engine. Here's a list of some of the main components that I've encountered anyway in the Docker world. The Docker engine is what's actually running the Docker containers. Then there's the Docker command, the CLI, to build and run and so on. Boot to Docker is a vagrant image that runs Docker machine, basically. Docker compose, I think Docker compose, well for me it's a very central tool. I think it's a great way to really organize what you're doing. Well, Docker compose uses YAML configuration files, so Drupal 8 people would be familiar with that syntax. Docker machine is one of the newer tools. It's actually replaced the command line interface of boot to Docker. But it's expanded. At Docker machine, you can connect to your local vagrant boot to Docker theme, but you can also use Docker machine to connect to the cloud. It's a very powerful tool. I don't know if it's pronounced chytmatic or chytomatic, but that's a GUI tool for OSX, maybe Windows. I'm actually a Linux guy, so I never tried that yet. It's for Windows as well. And I've heard there's actually a way to run it inside Docker if you want to try it in Linux. I haven't tried it yet. And then Docker registry. So that's for sharing your Docker images. That's a pretty loose way to put it. But yeah, Docker registry, you can very much like Git in my mind. You can kind of push and pull images. You can commit them. And then Docker hub is like GitHub. Docker hub is a public free service of Docker registry with even more features on top of that. Yeah, more details on that link. I should also clarify the difference between a Docker image and a Docker container. An image is something like, in a way, it's like a snapshot of a container, and a container is a running image. And that sounds cyclical because it kind of sometimes is. But you can also create an image from a Docker file very much like a Vagrant file where it builds an image. So a container is basically a running instance. And what can you put in a container? Yeah, anything. This is a picture of shipping containers put together to make a nice cottage. There's a lot of shipping containers in the world and people are being creative about them. But with a Docker container can be as big and complex as a virtual machine as you would have in a Vagrant example. But it can actually be so simple and small as a single process. You can have it run just... A container can just do echo hello world and then it shuts down again. And then you can have a better example, maybe it would be a container running a database and a container running Apache. But then the question is how to connect those together. So here's another interesting image. I've actually learned a bit about the shipping world and containers as I was preparing this. It's an interesting space. But shipping containers can be stacked together to make a city. But how do you connect them together in Docker? There's ways on the command line to do that where you can link a container to another container so that inside the container it knows how to find the other one via ETC host mapping and so on. But in my mind, this is a Docker compose YAML file. In my mind, this is a pretty simple way of understanding those connections. And I don't know, this is a simplified example maybe. I took this from a real project. But there's three components to it. There's the database container, PHP container, and the web container. So this project is running PHP-FPM. And so the database doesn't really need to connect to anything but the PHP container needs to connect to the database. So I don't know if you can see this in the back. Sorry, I just wanted to put this up as an example. But what we're doing here is we're defining the database. You say what image you want, MariaDB. You can set some environment variables so that when the container starts up it has these values. And then you expose ports. And then the PHP container, similar thing, you say what image you want to use, what command you want to start running. That's another nice option. But then the links section of PHP there, it links to the database container so that PHP has access to that. And then similar with the web container, EngineX connects to PHP. Anyway, that in my mind is an amazing way to use Docker because you can put that in your Git repository. You have infrastructure as code. You basically define your stack however you need it to be. More on Docker. I grabbed this image from the Docker website itself. I don't really know what's going on here. I recognize the penguin. That must be Tux, right? But it looks a little funny. But I think it's trying to convey Docker is fun. And I agree with that. I actually really enjoy working with it and messing around with it. Sorry, I really like getting to know what people are doing, but who's running Linux on your workstation? Awesome. I think this is a European thing. Okay, at least half I think. I'm running Linux as well on my developer workstation. When I started playing around with Docker, I downloaded it and it's like, wow, everything is super fast. This is an amazing tool. Then I played around with FIG at the time, which became Docker Compose. I was setting up Drupal on it and I thought this is absolutely amazing because we can do infrastructure as code. We can do lightweight things. We can switch projects easily because if I switch to another directory and do Docker Compose up, then there we go, it's up and running. I was just loving it. And then we're good to go. I look on the Docker website, check the installation documents, and there's a whole list of operating systems there. Earlier I asked who supports their development team. Does anybody support their development team sandboxes using Docker? A few, okay. Yeah, so I do that. I help people on board at Civic Actions. I get on a project and I help them get their tools set up or whatever, especially new employees, get up to speed with what we're using. Yeah, a lot of people use Macs. OSX is very popular. I got them to install Docker. And basically it looks like a shipwreck. So this is my impression of a Macs user experience of Docker. So it can be quite horrible. This is an image of a container ship that grounded. It's called Rena or something. Yeah, so it grinds to a halt. There's containers falling in the water. It looks horrible. So on Mac it is incredibly slow. And at first I couldn't figure out why. So I'm trying to support these people and I'm looking at my machine and everything's amazing. Then I look at theirs and it's falling apart. I found out through Googling that the way we were using it, we were using the official default boot to Docker that you can get still on the Docker website. It uses a file synchronization called VboxFS for synchronizing your files. So the Git repository to Vagrant. And then within Vagrant it's doing another synchronization to the containers. So it was all about file IO. I was running a test suite on my computer that took two minutes and it was taking 20 minutes on a very powerful Mac. What do we do about that? Well, since we found out it was about IO that we discovered there was another Vagrant image available out there on GitHub and to the rescue. There's another boot to Docker that we're using. Actually, it's landed in the room. I don't know if he's at the conference. Anyway, this is awesome. We've been using this for all our OSX users and I'm pretty sure it works with Windows. We actually don't have any Windows users. Sorry. I'm pretty sure there's ways of doing Docker in Windows but I don't have to worry about it. But anyway, there is good news for you on OSX. Yeah, and what the big difference was here is that instead of using the default Vagrant file IO sharing thing, it uses NFS and we are getting much better performance on running tests and on actual Drupal performance. So that saved us a lot of grief. And yeah, once we kind of got over that hurdle we're actually now using Docker for basically all of our current projects, all of our new projects. There's some old ones that we're still working on that don't have it. But our primary thing is going on right now. So Linux and non-Linux we're using Docker for our developers. So introducing Bolin. You can pronounce it Bolin. Anyway, Bolin is a knot. I enjoy sailing. I don't sail as often as I want to but every sailor knows the Bolin knot and I thought it's a loose connection to the shipping container metaphor. I don't think any containers use Bolins. But anyway, it's a loose connection. But anyway, what is this project? Basically it's a collection of simple bash scripts that bring things together for Docker. A Docker setup for Drupal. It's very Drupal focused. I basically started about a year ago on this. I forget when I put it on GitHub but this is what we're primarily using at Civic Actions for our projects. Originally it was actually inspired from the Drupal CI test bot. Cheers to you volunteers who are building that and everybody working on that. That's a really cool infrastructure. So I was taking ideas from that code from the Drupal test bot and then kind of reworking it for project sandboxes for creating a Drupal-based website. There's eight contributors for Bolin on GitHub but mostly it's all me but there's been a few great little pull requests. We actually hired one of the contributors, so cheers. I think we're still herring, so check it out. What is Bolin trying to do? There's project goals for Bolin. Flexibility. We work with a variety of different hosting platforms depending on the projects. Sometimes projects come with their own production and everything like that. So flexibility was really important to be able to also maintain old websites. So not just flexibility about deployment but flexibility even... What do you do with Docker 6? Drupal 6 all the way up to Drupal 8. We didn't want it to be too rigid for that so that means different PHP versions and so on. Another goal, quick start. The ideal is a new developer or developer comes on the project. We want them to just clone the Git repository and run build and it should do everything for them. The first time, we'll have to get Docker installed on their machine but once that's up and running, hopefully one command and you're there. Then import the database. Two steps. Minimal requirements. Docker allows, just with the lightweight containers, you can bake anything you want in there. That's something that we want to do more of. There's a lot more to add than what Bolin has. The way Bolin works, it's actually not... I think this is kind of distinctive in this space. Actually, you bake it right into your project repository so it's not a command that you have in your system like, I don't know, like Vagrant or so many other commands that you do. It actually is just a set of bash scripts that you would install right into your Git repository so that everybody has the same tools. This might be too small, but I'll talk through it. There's one line command to install it into your repository which is on the top there. You don't really need to know what it says. You can just copy and paste it off of the Bolin GitHub repository. Readme has this. What does that do? It actually creates a secondary remote. Just to clarify, this is not something like your whole dev team would need to do. You need to do this once, so maybe your technical lead for the project or something would want to try this out. You run this command. It adds Bolin as a repository to your local Git repo. It checks out the code. Then you can always do a diff, check what's going on. Then it actually has a series of prompts and it says would you like to build the Docker containers? The default set from Bolin will, I think it has PHP 5.5.5 something. The default will work with Drupal 8. If you need to do an old one, you probably need to do this and then hit no and do manual tweaks to get an older PHP and then carry on. What's happening here is it finished installing it and then say yes to build the containers. It does that. It actually runs the Docker compose command. Then it spits out the container IP addresses. That's the Docker subnet on your computer. If it's the web container, it also makes that into a link. Then if it's a brand new project, you maybe want to initialize the database with site install so you can hit yes and it will do the drush si command on that new. Or more likely you're doing this to an existing project so you want to get a database snapshot and import that. What is Bolin providing? As I mentioned, infrastructure has code. Essentially that Docker compose YAML file where you define your stack and check out the Docker compose documentation for all the things you can do there. It's also providing bash scripts so you can run your test suites and do your imports and backups and things like that. It's also written with the mind that you can easily add more things to those commands. There's a simple run command where you run your test suites so you can add what you need for that project. The tools, automation, it's all baked into your Git repository. Once you have Bolin installed, well then you can push it if you like it and then forget about it or you can even remove the Git remote if you're done with it. But then what do your developers do? Your developer team, they do the Git clone of your Drupal project. Then there's a command called activate. This is bash code. Works in ZShell as well. Then you source this activate so that's dot space bin slash activate and that just adds something to your path so that you have new commands available such as the following ones. You run build and that will run the Docker compose to start up the containers. Once the containers are up and running then you use settings in it and that will actually add a little snippet to the end of settings.php in Drupal and it will check if the file exists for the Docker settings and if it does it will include those so then Drupal will know from that command it will add that check then Drupal will know where to find the database. Then there's a pull command which is totally project specific so you kind of have to put in your own things there but pull will pull in a database snapshot so you need of course your credentials to your project, SSH keys but we have pull set up to pull in that or you can also have a pull in any assets, file assets into your sites files folder. Basically you put in the pull script whatever the developer needs to download including of course the database snapshot the import command obviously imports the SQL snapshot into the database and you're done. Then drush you alive of course gives you login and when you run drush it's an important note it's actually running drush and it's doing a Docker command to run drush so it will do a Docker exec something but that drush will run drush inside of the running container so all of your drush commands like drush you alive will do that it will give you your login if you want to clear cache whatever so yeah command highlights I already went over a bunch of these by those prefix no, that's a current discussion because I want to make it available both ways I had a discussion with one of my coworkers about that that it might be more intuitive to have it like Bolen build and Bolen import but right now what that funny line is doing the dot space bin slash activate that's changing your path so that it includes the files in your project slash bin directory which is installed in the git repo so those are actually just bash commands and so maybe that makes sense for build or whatever then drush it's actually overriding your drush command so if you want to use your own drush installed on your computer then you just run deactivate or open a new bash session so I kind of want to make it work both ways but right now it's working in this activate mode which is working for us but it would be good to have it work either way depending on what the developer wants to do so yeah we already talked about build and import another command is check that's a fairly new one I added but that attempts to go through your system to make sure everything is running that you need for docker to work like it does a docker version and if it sees that it can't connect to the docker engine then it will fail and say fix this or whatever or you need to run vagrant or whatever it is so it's just a series of checks pretty handy for doing support it kind of made things easier for me basically but a collection of the common problems that I've seen people have that I've been supporting I put it into a bash script so that might help solve problems for other people I hope to build import backup just creates a snapshot of the database run I think I already talked about that but that's the intention of running your test suite whatever that might be as I was saying when you do activate these commands are then overriding your existing commands if you have them so your developer doesn't have to have drush installed but if they do then they activate but once they exit or deactivate or open a new bash session then they get their original drush again same with composer composer will run PHP composer in the container if you need to do composer install or composer whatever PHP CS for code sniffing that also runs inside the container so your whole dev team is running the same version of all these things oh cool I have a broken image on my version here but it's up there, that's cool so Drupal 8 another part of boleyn is something called the hoist command and that's another sailing metaphor I guess but you can hoist the main sail but the idea there is instead of installing just what the default boleyn provides to get you up and running you can also pull in other whatever it is so Drupal 8, all you have to do is hoist Drupal core dev and if you want to instead of working on a Drupal project for a client if you want to work on Drupal 8 core there you go if you've had like if everything's up and running already like you have a boleyn installed to do this it will bring up it will actually get clone Drupal 8 and move it to the dock root folder and go through that build step and give you the the IP address and then you can do drashulai again and whatever other examples vhat codeception so out of the box boleyn doesn't provide these but you're testing infrastructure you probably maybe you want to bring vhat into your code so everybody your whole dev team can have we're using vhat but codeception is also a great looking project but then everybody's got the same version of vhat because it's running inside a container so you just run that command it actually just changes things in this case it changes things in the composer json file and some I think it's like five lines of code to do that and creates some test directory and actually runs the test alright so that was developer sandboxes then when we get to our cei we want to run a full test suite we don't want to the developers aren't going to run the whole suite it takes a half an hour or more depends what you're doing on how many tests you have but yeah it basically are so who's using Jenkins so we yeah almost everyone more than the Linux users so Jenkins basically really advanced task runner this is I pulled this change the project name but I pulled this from one of our projects one of our Jenkins projects this is a build step just a few lines of bash so we change into the directory we activate we build add sleep because that solved an error and then we run the full test suite and this is very similar to the developers experience because they just activate build and they're up and running so oh and there's no import in this one because there's a bit of a tradeoff I actually have another Jenkins build that does the import so it depends how long your import takes but there's a tradeoff for accuracy and time we wanted to see test results a little sooner so I have another one that looks just like this but it doesn't do run it does import to get a fresh database snapshot okay going back to sandboxes some key challenges that we faced as I already mentioned was the file synchronization that's the third point but yeah the boot docker from blink reaction that one kind of solved that for us another problem that we've come across if you're developing sorry if you're supporting your developers on docker you might come across this but the docker API changes so if you upgrade docker to 1.8 and your developer was on 1.7 then their vagrant might be on 1.7 and then it doesn't work and shipping containers fall in the ocean and then file permissions going backwards up the list file permissions was a challenge early on where you test uploading a file and then it screws up whatever lots of file like PHP errors can access so and so file and that's actually solved in Bolin with a docker entry point excuse me the docker entry point is sort of the first thing that gets run when the container starts and what it does is it checks the VARWW directory which is the mount point of your project it checks the user ID of that which is your user and it sets Apache to run as that and it sets PHP to run as that user so within the container the file permissions problems that we had at the start so that kind of describes Bolin but I also want to point out this isn't the only way of doing Drupal on docker there's a list here I don't know if I'll mention all of them yeah maybe the vagrant boot to docker that we're using goes along with another tool called Drude I haven't gotten around to trying it yet but it does look really good there's an official from docker there's an official Drupal image I tried it briefly I haven't gotten too far with that one another one is Calibox I haven't tried that because I'm a Linux guy I think it works on Linux now they had a presentation in LA and their new version is docker based I can't really speak to what's going on there but it looks like a really slick project too I think it's sort of the opposite end of the scale of Bolin it has a lot of stuff it does a lot of things and Bolin is really trying to be lightweight and minimal I don't know why that's here actually because it's not really offering Drupal on docker and then yeah basically you can just try vanilla docker tools you can put together your own docker compose files in your own project and docker machine oh there's another project docker machine NFS and that will change the official boot to docker vagrant machine to use NFS I tried it but it didn't work on Linux so maybe it works on OSX anyway just to say that there's a lot in this space going on right now it's a fastly moving yeah it's a fastly moving space I think it's hard to keep up with but there's alternatives to look at back to Bolin I asked my co-workers what do you love about Bolin they had a bunch of encouraging responses but I think the most significant one is the third one I love that Bolin comes with the Dave N attached at the other end of the line which says a lot about what tools you use is what tools can you support and I don't do all of the docker support but I do most of it so yeah so when you're choosing what tools you want to try consider how you're going to maintain and support it alright another thing that I hope we have enough time to talk about is deployment so let's get this thing running on live so right now Bolin basically tries to stay out of the way of what's going on we're using a variety of hosting platforms we're on AWS and we have our own servers so there's a mixture so we need to be able to deploy and basically you can use docker for your developers and not use docker in production that's what we're doing but the ideal is that you have the same experience because we're using it for testing as well so same experience for Jenkins as it is for the developers the ideal is that you also do that in production but the current reality is I mean there's Pantheon Aquia AWS and many many ways of hosting live Drupal when we think about taking what the developers are working on and bringing it through the pipeline like a developer pushes their code then it goes through automated tests then it goes through a full test suite then there's another manual QA step user acceptance tests then you put it in production what we typically have there is basically a git commit or a git tag or whatever which is still a git commit that ends up on production so then on the prod you might do a git pull and you set your tag you have to run drush updb you have to update your drupal database and that works very well that's basically how we do it. Another way that the DevOps world is seeing production happen is actually following a docker image so you create your code and you and get and everything and put it through your CI but what you're doing instead is creating a docker image with your code in it and that image is going through your pipeline steps then when we get to the point where it's ready to deploy then you can actually just switch the running images around in your deployed because you can do your update database before it goes live we're not doing that yet but this is sorry in that concept of moving a docker image through your pipeline I think that's basically described as immutable infrastructure so it's not changing it's this thing that you know is not changing all the way to production so that's something that we're working on that we're working towards I think the drupal devops community is maybe working on that too and the way I mean I also think about what is the ideal deployment we had our civic actions retreat a couple weeks ago and one of the best times is making music together this is four of my coworkers talented bunch and there's a lot of musical talent but basically there's this jam session at the retreat and I don't know there's a dozen musical people and they're just seamlessly making music all even like a player or two get in and out so you switch out a guitar player and they're still making great music and that I think is a metaphor for seamless deployment on production that we want to aim for where you can switch out even just features or something that you're adding to your production to your production site further ideas about things that we're working on okay I actually want to have more time for questions so I'm just going to do this first point here I talked a lot about running the boot darker vagrant thing which runs on yeah which runs vagrant that actually for OSX users that actually there's a resource strain on your computer because you have to run two computers so an idea that we're working on is cloud development where we're using Docker machine or something to connect to a running Docker engine out there on a server for developers another idea we have is to have a local headless device like a super powered battery pie or something something like that where you just plug it into your network and it's the same kind of thing but then you're taking the processing away from your development computer not really an issue in Linux because you only need one OS yeah and some of these other ideas I'd love to talk more about the production deployment to production using Docker but I just want to wrap it up in my yeah just broad strokes perspective I think Git has really changed the way code management has allowed for new workflows I mean GitHub, the pull request thing is nothing like we've seen before Git existed I think Docker is still pretty new but it's really revolutionizing infrastructure and deployment yeah and I think it's an exciting place to be a part of Docker is an exciting community to watch so keep an eye on it some takeaways Docker Docker infrastructure can support your development team and your testing and production I think that can be proven Bolan might be a way for you to get up and running using Docker and Drupal but there's other options yeah and if while at the conference you want to try out Bolan look for me or try it out and let me know what broke but I'll be around and finally really I think Docker is fun I want to say thank you very much for your time but also before you applaud maybe is there any questions there's a microphone there feel free to if you want me to go back and cover something bit more or any questions but also review sorry there are a lot of people working on these sort of Docker local development tools we have a BOF setup for 345 at room 130 today and we're going to the Tera folks hopefully the FFW folks will be there so we're getting like kind of show and tell with each other if everyone else is interested in trying one or out you want to see people demoing it on the computer we're going to be there so hopefully you can be there too yeah that's great I was hoping there would be a BOF but I didn't find that one when I checked room 130 at 345 just don't comment about the Drupal project there is also the TeraOps project which is similar to Bowline and it's made by John Peck they are doing something like you especially for Drupal and Drupal 8 but it's not so much built for for CI and such but you can also add it into the list T-E-W-R DasOps it's on GitHub okay Tera, T-E-W-R A, DasOps all right a lot of to all right