Working with Azure container service cluster [Tutorial]

Azure Container Services is a new variant of the classical Azure IaaS offer from Azure and uses virtual machines as the technological base.

This tutorial is an excerpt taken from the book,  Implementing Azure Solutions written by Florian Klaffenbach, Jan-Henrik Damaschke, and Oliver Michalski. In this book, you will learn how to secure a newly deployed Azure Active Directory and also learn how Azure Active Directory Synchronization could be implemented.

Today, you will learn how to create a process and work with Azure container service (ACS) cluster.

As an important prerequisite, to work with the cluster, you need the Master FQDN (a URL). The Master FQDN can be found in the Essentials section of the dashboard of your container service.

Now that we know the important prerequisites, we can go further.

Each of the three available orchestrators provides you with a work surface. To work with these UIs, you must first create an SSH tunnel.

You don’t know how to create an SSH tunnel?

Then I want to bring you closer to the procedure by the way of an example. I assume that you have followed my earlier advice and have installed the PuTTY toolset. I also assume that your SSH key pair is available.

Everything okay? Then let’s start:

1. Search for the PuTTY tool and then open the tool:

2. On the first page, fill in the Host Name field. The hostname is composed of the admin username (from your cluster) and the Master FQDN and has the format adminusername@masterfqdn. Change the Port to 2200:

3. Now switch to the Connection | SSH | Auth site. Here you enter the path to your SSH private key:

4. Move to the Connection | SSH | Tunnels site. In the Add new forwarded port section, type 80 in the Source port field and localhost:80 in the Destination field. Finally press the Add button:

5. Now go back to the first page. Press the Open button and the SSH tunnel is built up:

Have you created your SSH tunnel now?

If yes, we will look now at the work surfaces once. Remember, since we have created our cluster based on DC/OS, it is the UIs of DC/OS. The UIs of the other types are very similar.

Let’s start with the DC/OS dashboard. To reach this UI, enter the following URL into the browser of your choice:

http://localhost:80/

With the DC/OS dashboard, you can monitor the performance indicators of your cluster or display the health status of individual components:

If you want to see the health status of individual components, click the View all 35 Components button in the Component Health tile:

 

A detailed list with the corresponding status information will open:

In the DC/OS dashboard, you will also find another interesting application. Simply press the Universe button in the navigation area. This starts mesosphere universe.

Mesosphere universe is a package repository that contains services like Spark, Cassandra, Jenkins, and many others that can be easily deployed onto your cluster:

In addition to the solutions provided by mesosphere, there are still solutions from the community. Just scroll the page down:

The next area is the MARATHON orchestration platform. To reach this UI, enter the following URL into the browser of your choice:

http: //localhost:80/marathon/

With this UI, you can start a new container and other types of application in the cluster. In addition, the UI also provides information on executed containers and applications and is constantly on-going for planning tasks:

Two short examples:

• The following screenshot shows the dialog for creating a group. A group in DC/OS is a collection of apps (services, and so on) that are related to each other (for example, over the organization):

• The next screenshot shows the dialog for creating a New Application. An application is a long-running service that may have one or more instances that map one to one with a task:

Internally, the user creates an application by providing an application definition (a JSON file). Marathon then schedules one or more application instances as tasks depending on how much the definition is specified.

In the original concept of DC/OS, there is still another part, the pods. A pod is a special case of an application. A pod is also a long-running service that may have one or more instances but map one to many with collocated tasks. Pod instances may include one or more tasks that share resources (for example, IPs, ports, or volumes). Pods are currently not supported by ACS.

The last area is the Mesos. Mesos is a web UI for viewing cluster state, and above all tasks. To reach this UI, enter the following URL into the browser of your choice:

http: //localhost:80/mesos/

The following screenshot shows the UI for Tasks:

The next screenshot shows the UI for Frameworks. A framework running in Mesos consists of two components: a scheduler that registers with the master to be offered resources, and an executor process that is launched on agent nodes to run the tasks:

The next screenshot shows the UI for Agents and its conditions:

The last screenshot shows the UI for Offers. An offer in Mesos is simple a resource (for example, container), and is assigned to a framework for processing:

In this post, we learned how to work with clusters in Azure Container Service cluster. If you’ve enjoyed this post, head over to the book, Implementing Azure Solutions to learn more on how to manage, access, and secure your confidential data, you will implement storage solutions.

Read Next

Microsoft’s Immutable storage for Azure Storage Blobs, now generally available

Machine Learning as a Service (MLaaS): How Google Cloud Platform, Microsoft Azure, and AWS are democratizing Artificial Intelligence

Modern Cloud Native architectures: Microservices, Containers, and Serverless – Part 1