Tag: Docker

Learn Docker 1.12 and Swarm Mode Interactively with Katacoda

Katacoda is an interactive technical learning platform for software developers. The platform provides environments that are uniquely accessible via the browser, with no need for configuration or download

With over 70 free interactive scenarios, people come to us to learn cloud-native technologies like Kubernetes and Docker.

We want to help people see the overall picture and enable users to start solving problems. To support with Docker 1.12 and Swarm Mode, we have put together five initial scenarios that explain how to run containers at scale.

Each scenario has a step-by-step tutorial to guide users on how to solve a particular problem and complete a task. Alongside this, we provision each user with a free Docker Cluster that’s accessible directly from your browser without any downloads or configuration within seconds. Starting learning at https://www.katacoda.com/courses/docker-orchestration/

While step-by-step guides highlight how to solve problems, sometimes it’s useful just to play. This is why we always include playgrounds. A space to experiment, try commands and see what happens. If it all goes wrong, hit refresh and be allocated a clean new cluster. Try it at https://www.katacoda.com/courses/docker-orchestration/playground

Katacoda has a range of courses, covering Docker in development and production, Container Security, Kubernetes and more! Visit https://www.katacoda.com/learn

Changing times at Cisco with Mantl, Contiv, Shipped and Cisco Cloud

Until recently I considered Cisco to be a company that focuses primarily on data centres and networking hardware. Last week and attending Cisco Live event made me change my mind. Times are changing! Cisco is changing.

The last three years have introduced dramatic changes to the infrastructure ecosystem. Container technology has become accessible. Scheduling platforms like Mesos are in use outside of the top SV companies. Automation of deployment process is possible with amazing tools like Terraform and Ansible. The style for microservices, or component-based architectures, has been born. Many developers will simply consider micro services to be another buzzword, a new term to think about known ways of architecting systems. While this is true, the latest conversations have relighted the risks of monolithic systems. They introduced new questions about deploying these components as globally distributed services.

These questions are causing many sleepless nights in developers world. The learning curve to understand all the moving parts is steep. Some days I believe to the point where it’s almost vertical. I’m currently working on solving this problem with Katacoda. It’s an interactive learning platform dedicated to helping developers understand this rapidly changing world.

Cisco and their partners are creating tools to answer similar questions. They consider issues like deployment distributed services and utilisation of available open source tooling. During Cisco Live the majority of the conversations gathered around the Cisco Cloud team. As the solution with support from Container Solutions, Remember to Play and Asteris, Cisco has built Mantl.

According to Cisco Mantl “is a modern platform for rapidly deploying globally distributed services“. From my perspective, it’s creating a best of breed platform. It combines the finest open source systems making them simple to deliver as end-to-end solutions. This aim is achieved without any vendor lock-in and by releasing the product under the Apache License. This way the platform fits into “Batteries Included But Removable” mindset.

Mantl is the glue to connect services and infrastructure together. Out of the box, it manages the provisioning of infrastructure and software using code artefacts. It manages deployments using Ansible and Terraform. This means supports the major cloud platforms. This continues by deploying your software onto a Mesos cluster, software defined networks via Calico, service discovery using Consul, and logging with the ELK stack, to name a few. All managed under source control, exactly where it should be.

Mantl Architecture

The architecture of building on top of existing tooling is significant. By not re-inventing the wheel, Mantl becomes an appealing platform as a combination of your existing go-to tooling.

Container Solutions, presented an impressive example on how to work with the platform. They have put together case study based system collecting data for localised fog predictions. Who doesn’t like IoT, big data and drones?

The resulting architecture like something we built for a previous client that involved predicting faults. In theory, if we had used Mantl then we’d have saved significant time and investment on our infrastructure work. We used the ELK stack, Consul and many other tools Mantl is based on meaning it would have felt similar. We’d also have gotten the benefits of running on top of Mesos/Marthon for free. As a result, the team could have spent more energy on data analytics instead of infrastructure.

Mantl provides an interesting future and direction. The container ecosystem is still young with no clear winner. Mantl’s approach feels sane as it’s agnostic to the underlying tooling. As a result, it has the potential to win the hearts and minds of many users.

But it’s not going to be an easy task. One of the main challenges I foresee is shielding users from the underlying complexity as the platform grows. It’s important to keep the initial setup a simple and a welcoming process. Another aspect would be educating users in using Kibana, Marthon, Vault, etc. once it’s up and running.

Ensuring the platform is easy to get started with is the key. I’m seeing too many platforms attempting long sales approach that’s putting developers off. Developers don’t want to jump through hoops to start playing with technologies. One of the worse things companies can do is force them to join a “Sales Call” to see if they’re suitable. The great aspect of Mantl is it’s open to everyone. By using familiar tooling like Ansible, Terraform and Vagrant, the platform allows you to get started quickly. Other “Control Planes” should take note.

Mantl wasn’t the only interesting project discussed during the conference. Shipped is a hosted CI/CD/PaaS platform that uses Mantl under the covers. Mantl provides deployment of your application onto a Mesos cluster in AWS and other cloud providers as it’s completely cloud agnostic.

Using Make To Manage Docker Image Creation

Like source code, Docker images are required to be built, tested and deployed before they can become containers.

While Docker doesn’t have a build framework, you can take advantage of Make to automate the build process across different environments. By using Make you can have a consistent and shared approach to managing your Docker images without the overhead of using task managers such as gulp.

To execute commands you need a Makefile. The Makefile contains a list of targets that define the commands and arguments required to be executed in order for a particular task to be performed, such as building a Docker image.

The contents of a Makefile might look like this:

build:
    docker build -t benhall/docker-make-example .

With this in your project’s root directory, executing the command `make build` will now build the container image.

A Makefile can define multiple targets reflecting different actions. The template below demonstrates a useful Makefile template covering the common scenario’s for managing Docker images.

NAME = benhall/docker-make-demo

default: build

build:
    docker build -t $(NAME) .

push:
    docker push $(NAME)

debug:
    docker run --rm -it $(NAME) /bin/bash

run:
    docker run --rm $(NAME)

release: build push

Learn Docker and Makefiles via Scrapbook, an Interactive Learning Environment.

Docker and Makefiles

Running NancyFX inside a Docker container

A number of years ago I described how to run a NancyFX based application on Heroku via Mono. Recently I’ve been focusing my attention on Docker and considered the same problem, how can you run NancyFX as a Docker container? At a high level, a Docker container is an isolated process comprising of the application and it’s direct dependencies. With everything isolated we can manage multiple containers more effectively. More details can be found at https://www.docker.com/whatisdocker/

It turns out to be fairly straight forward. Firstly you need a Docker image with Mono installed which I’ve previously built and made available an image at https://github.com/BenHall/docker-mono

This image can be used as the foundation for the Nancy project we want running inside the Docker container. A Docker container is baed on an image that can be pre-built and shared. These images are created based on a Dockerfile, a set of commands that are executed in order to configure and run the application.

A Dockerfile for a NancyFX first needs a base Docker image. In this case we’re using the image created with Mono installed.
FROM benhall/docker-mono

We then copy the source code for the application into it’s own directory.
COPY . /src

Setting the working directory ensures that future commands are executed from inside this folder
WORKDIR /src

Using xbuild we can compile our project
RUN xbuild Nancy.Demo.Hosting.Docker.sln

As the application is sandboxed and isolated we need to expose any ports which we want to be accessible. In this scenario the self-hosted web app maps to port 8080
EXPOSE 8080

Finally, when the container boots up we can specify which application needs to run.
ENTRYPOINT ["mono", "src/bin/Nancy.Demo.Hosting.Docker.exe"]

This is everything required to define a Docker image capable of running a Nancy project. The complete file can be found at https://raw.githubusercontent.com/BenHall/nancy-demo-hosting-docker/master/Dockerfile

To launch the container we first need to build the image. This image can be reused, shared and made available for other environments or people to use. Using the -t we can define a friendly tag to help recognise the image followed by the path to the repository or directory containing the Dockerfile
$ docker build -t benhall/nancy-demo-hosting-docker github.com/benhall/nancy-demo-hosting-docker

Once built the image can be started as a container with port 8080 accessible.
$ docker run -d --name nancy-demo -p 8080 benhall/nancy-demo-hosting-docker

Inside the container the NancyFX site is up and running. The docker port command tells us the port number of the host mapped to the port inside the container. This allows us to run multiple identical containers on a host as they’ll all be assigned different ports.
$ docker port nancy-demo 8080
0.0.0.0:49153

A quick curl and you can see the Nancy and Mono response headers from inside our container.
$ curl -I 0.0.0.0:49153
HTTP/1.1 200 OK
Nancy-Version: 0.9.0.0
Content-Type: text/html
Server: Mono-HTTPAPI/1.0

While this is a simple example it demonstrates the starting point of how you can create isolated and repeatable containers for different parts of your software stack. With the recent announcement that Microsoft and Docker are working more closely together this is here to stay and the future of how we deploy software. If you’re interested in hearing more then I’m speaking on “Architecting .NET Applications for Docker and Container Based Deployments” at NDC London in December. Alternatively please feel free to email me (Blog @ BenHall.me.uk) or via Twitter (@Ben_Hall)