The course is part of this learning path
DC/OS: Container Orchestration
Container orchestration is a popular topic at the moment because containers can help to solve problems faced by development and operations teams. However, running containers in production at scale is a non-trivial task. Even with the introduction of orchestration tools, container management isn’t without challenges. Container orchestration is a newer concept for most companies, which means the learning curve is going to be steep. And while the learning curve may be steep, the effort should pay off in the form of standardized deployments, application isolation, and more.
This course is designed to make the learning curve a bit less steep. You'll learn how to use Marathon, a popular orchestration tool, to manage containers with DC/OS.
- You should be able to deploy Mesos and Docker containers
- You should understand how to use constraints
- You should understand how to use health checks
- You should be familiar with App groups and Pods
- You should be able to perform a rolling upgrade
- You should understand service discovery and load balancing
- DevOps Engineers
- Site Reliability Engineers
- Familiar with DC/OS
- Familiar with containers
- Comfortable with the command line
- Comfortable with editing JSON
|Lecture||What you'll learn|
|Intro||What to expect from this course|
|Overview||A review of container orchestration|
|Mesos Containers||How to deploy Mesos containers|
|Docker Containers||How to deploy Docker containers|
|Constraints||How to constrain containers to certain agents|
|Health Checks||How to ensure services are healthy|
|App Groups||How to form app groups|
|Pods||How to share networking and storage|
|Rolling Upgrades||How to preform a rolling upgrade|
|Persistence||How to use persistent storage|
|Service Discovery||How to use service discovery|
|Load Balancing||How to distribute traffic|
|Scenario||Tie everything together|
|Summary||How to keep learning|
If you have thoughts or suggestions for this course, please contact Cloud Academy at email@example.com.
Welcome back. In this lesson we're gonna see how to use DNS based service discovery that comes with DCOS. Distributed Micro Services are not all fun and games. Your services need to be able to interact with each other, which means you need to know how to find the services and which ports they're mapped to.
There are different ways to handle this, and the approach Mesos has taken, is to use DNS. Using DNS has pros and cons. One of the pros is that DNS is familiar and easy to interact with programmatically. One of the cons is that DNS doesn't really think of things in terms of non standard ports. For example, when your browser connects to a web server, the assumption is that it's going to use port 80.
If another port is used, then you have to know about it and append that to the end of the domain. Like many DNS based service discovery options, the solution here is to use the SRV record which contains the port number. Now this is a viable option, however it's probably going to need a code change if you want to use the SRV lookup.
While there maybe some networking libraries out there that use the SRV record or are SRV aware, I haven't used any, so I'm not sure where they are. Luckily, there's also a rest API option that you can use to get all of this info. So let's check out both. First, there needs to be an app so that we can have some service to discover.
So I've created an app based on Mini Twit, which you've already seen a few times in the course. So to demonstrate out the DNS stuff, let's SSH into the master node so that we can query the DNS records. Okay, here we are. I wanna see if dig is installed, so I'll just type dig, and it is. Let's check out quering A records.
When a new container starts up, it registers a new record with Mesos. So Mesos uses the following pattern, taskname. framework. mesos, we're using marathon so the framework is going to be marathon and the task is mini twit. So we can query an A record from mini twit. The command is digminitwit. marathon. mesos, and you can see it returns the A record showing the IP address for the instance.
The pattern for SRV records are slightly different. You use the task name with a leading underscore, then the protocol with a leading underscore, then the framework name, followed by mesos. Let's try it out. Digsrv_minitwit_. underscore tcp. marathon. mesos And if you notice the answer section, it shows that the port is 80 and it's followed by the service URI.
And then the additional section here shows that the service URI is resolved to an IP address. Mesos also has additional records for things like the master enslave agents. You can query things like leader. mesos and that will show you the IP address for the leader. You can query master. mesos to find all of the masters.
You could also query slave. mesos to find all of the slave A records. So if you're inside the cluster and you want to interact with the different components that master the slave, the master that is the leader etcetera, you can use the DNS records for that. From inside or outside the cluster, if you want to use the rest API, you can use the API to interact with the SRV record and find out more information about the different tasks and where they're running.
So let's check out that by adding mesos_dns/v1 to the URL, and we'll add /config to the end. And this will show some high level config settings. But the more interesting endpoint is the enumerate endpoint, and the enumerate endpoint shows all of the records for running tasks. So, between the SRV record and the rest API, you have different ways of handling service discovery and that'll wrap up this lesson here.
In the next lesson, we're going to check out load balancing. So if you're ready to keep learning, then I'll see you in the next lesson.
About the Author
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.