What is Docker

James Kayes-Smith
A free video tutorial from James Kayes-Smith
Exerienced Dev/Ops
3.5 instructor rating • 1 course • 12,127 students

Learn more from the full course

Docker from A to Z™: Swarm + Jenkins

In this Docker complete training, you'll master Docker with Jenkins, DevOps and AWS.

08:48:52 of on-demand video • Updated March 2018

  • Build and Manage a Docker cluster
  • Use Docker Compose
  • Use Docker Swarm
  • Use Docker Registry
  • Use Jenkins
  • Gain practical Docker experience with real-world examples
English [Auto] Everybody this is a practical guide to doctor Dr. swarming. Jenkins My name is James K. Smith and I will be your instructor for this course. So just a quick intro like I said my name's James. I worked nights here are four to five years. I have a variety of experience from front to back in development. I've also done a lot of stuff in dev ops. I have worked for a variety of companies from government entities to retailers to small start ups. I've seen a wide variety of architecture infrastructure and deployment models. So hopefully that will help. Any questions you may have about your specific needs and I will try to address those when you have them. Main goal the main goal here is to build and manage an enterprise worthy docker cluster behemoth. So this is essentially something where you can deploy tons of applications have them highly available scale them up scale them down and make sure that they're completely balanced. It will you'll be able to deploy these with the push of code so you'll have a get repo. And anytime something pushes to it it will kick off a build that will test your code. That will then create a container and then deploy it to your cluster. So and then we'll go over some ways to do alerting for your application if it were to God forbid go down or you know screw up. We'll also look into ways to do hotfix is such a scaling on the fly you know creating multiple instances using a front end group rather than doing everything through duck or Selye. All right. So to get to a awesome Doctor cluster we really need to know why containers are awesome themselves. So first what's a container so a container is kind of like a VM but it's not a VM it's a walled off application within a single host such as a VM or an actual Linux computer. So when you're inside this container it really looks like a standalone Linux VM. You know it has its own bin directory it has its own user userspace it's it really feels like it's an entity and essentially what you're doing with this container. What you would want to do with this container is package everything you would need for your application. So it's it's the tightest package delivery from from a environment perspective. So all of your libraries such as you know all of your command line utilities that you would need if you need a curl if you needed a specific version of Java if you needed a specific version of of whatever it didn't matter anything that you need it whatever you would need for your application to run. You would just need to make sure that it's package inside of your container so that I understand kind of why containers are a step in the right direction. We kind of need to know where we've been. So to know the the most popular form of deployment and packaging was via fat jars and app servers. So you'd essentially have an infrastructure layer that would have your racks of servers and the hypervisor layer that would contain that would have vse fear that would be the sphere. And then you would use that to spin up the IMs and then on that VM you would either deploy a fat jar or you'd have a web application server where you would deploy a simple draw and a war file. So this has been a great a great deployment mechanism as long as all your apps are very similar like they're all using Jarre they're all using an app a web application server to be deployed. But as you will learn in any type of company or anything no matter how big or small you end up needing to add more apps you needing or add more services and Sue Usually you do have some amount of constraint for costs so you try and put multiple apps on the same be and eventually gets to the point where all your apps aren't looking the same and you're not going to be able to pull all your apps on that same VM because of library conflicts because of a need to do load balancing because of a variety of reasons that you would need to spin up multiple beams you're hitting the max. So you need to make sure that you create a new VM to offload the application onto something with more availability. So you're doing a lot more thinking about where you're deploying to and then you're not only thinking about where are you to point to but you have to make sure that that environment that you are deploying to said the VM matches where what you've worked on in development. So you have to make sure all your environment Vians are as similar as possible. Whether it's production or your local or staging or development you have to work with your infrastructure team or you have to work with your operations team to make sure that everything is exactly the way it is and that there's nothing mishandled. Which doesn't always work perfectly. So what's a better way. So what's a better way. Obviously it's containers that or we wouldn't be doing this video. So more specifically docker is what we're using as sort of the the front runner for container container creation and manager at the moment. So it's it's definitely been the industry leader. Everybody's using it from Google to Microsoft everybody supporting Dr. containers. So how does a container deployment model look and why is it better. All right so what we had before with four separate VAMC that all had conflicting libraries and required their own vim's. You can now deploy at each of those. All of those on the one VM using Gawker's so within each container I have all of the individual needs of that app. So if this one has Java 8 and this one is Java 7 that's all cool it's all good. They won't conflict with each other. They don't even know that the other exists. They think they're the only thing running on this and they only see what our container allows them to see of the environment. So you get a lot more flexibility from a developer's perspective on making sure that your container is perfect for the application that you need. And you know because the way the containers work they're all packaged together as an image that whenever you move this image from production or from staging to production or from development to station you know that you're going to have identical identical reactions from from that container as long as it has a doctor. It should be able to handle the application in the exact same way. So that's sort of why the benefit. The major benefit of moving to a container deployment model is that it's a lot easier to have the same look at from your different lifecycle is from staging to production as you're in the same thing as your local. And then also allows for you to not worry about whatever's installed on the VM as long as stockers install. So that leads us to our next thing getting docker installed.