In our fourth part of Microservices – Legolizing Software Development we will focus on our Continuous Integration environment and how we made the the three major parts – Jenkins, Docker and Git – work seamlessly together.
Now that we’ve understood the basics, this second part will cover the most relevant container threats, their possible impact as well as existent countermeasures. Beyond that, a short overview of the most important sources for container threats will be provided. I’m pretty sure you’re not counting on most of them. Want to know more?
MirageOS is a new and rising trend when it comes to talking about cloud computing. More and more services are being relocated into modern cloud infrastructures, due to a lot of advantages like i.e. reduced costs, maximum flexibility and high performance. Todays services normally depend on big virtual machines (like i.e. Ubuntu Xenial with a size of ~1,5 GB) with a lot of software on it. The service which is running on these virtual machine only needs a very small subpart of the whole software and dependencies which are installed. Also the unneeded additional software running on the virtual machines offers a huge attack surface for hackers. Since data often is a highly valuable asset for a company and exposing it would lead to a huge profit collapse, security gains more and more importance. MirageOS is a minimalistic approach to kick out all unneeded layers and dependencies and deploy as less code as possible. This approach is highly efficient and fits in perfectly in modern microservice-architectures. If MirageOS will be accepted by users in the future, it could possibly replace modern approaches like i.e. Docker or classic virtual machines in the context of cloud-environments.
When it comes to Docker, most of us immediately start thinking of current trends like Microservices, DevOps, fast deployment, or scalability. Without a doubt, Docker seems to hit the road towards establishing itself as the de-facto standard for lightweight application containers, shipping not only with lots of features and tools, but also great usability. However, another important topic is neglected very often: Security. Considering the rapid growth of potential threats for IT systems, security belongs to the crucial aspects that might decide about Docker (and generally containers) being widely and long-term adopted by software industry.
Therefore, this series of blog posts is about giving you an overview of the state of the art as far as container security (especially Docker) is concerned. But talking about that does not make so much sense without having a basic understanding of container technology in general. This is what I want to cover in this first part.
You may guessed right: Altogether, this will be some kind of longer read. So grab a coffee, sit down and let me take you on a whale ride through the universe of (Docker) containers.
So you have written the uber-pro-web-application with a bazillion of active users. But your requests start to get out of hand and the Raspberry Pi under your desk can’t handle all the pressure on its own. Finally, the time for rapid expansion has come!
If you have already containerized your application, the step towards clustering your software isn’t that hard. In this post, we want to shed some light on management tools you can use to handle a cluster of Docker nodes.
To benefit from using a loadbalancer we need several machines to distribute the traffic on, evidently.
Thanks to Docker we simply run
docker run -d -p 81:80 testwebsite:1
to get a second machine. This time the container port of the webserver is mapped to port 81. If you now visit <IP OF YOUR VM>:81 you should see your test website.
You can have as many machines as you want to. Simply pay attention to the ports.
Of course we don’t want to write this command manually each time when we want to create a new container. Especially not when we want about 100 new containers. That’s why we wrote a small bash script, which does the job for us.
In the first part of this series we have set up two VirtualBox machines. One functions as the load balancer and the other will house our services. As the next step we want to install docker on the service VM. To do that enter the following commands in the bash:
$ wget -qO- https://get.docker.com/ | sh
$ sudo gpasswd -a <username> docker
$ newgrp docker
This downloads and installs Docker, adds your user to the docker user group and logs you into this new group to allow you to create and run containers.
This series of blogposts will focus on the effects on response times when performing different tasks running on a variable number of docker containers in a virtual machine.
What will be the performance differences running a small or large number of containers on the same machine? These posts will function as a step-by-step tutorial, enabling everyone to reproduce our studies.
In production one of the most scaled services are webservers. Therefore, we want to focus on stress testing a self hosted website that is being load balanced and running in a varying number of Docker containers.
Docker has gained a lot of attention over the past several years. But not only because of its cool logo or it being the top buzzword of managers, but also because of its useful features. We talked about Docker quite a bit without really understanding why it’s so great to use. So we decided to take a closer look on how Docker actually works.
In this article, we want to shed some light on a few technologies used by Docker enabling it to be so lightweight and fast in startup compared to “traditional” virtual machines (VMs). Docker itself serves us as an example, you could replace it with any other container technology, for example LXC.
Reading this article requires some profound knowledge of virtualization. Terms like “guest system” or “hypervisor” should ring a bell. Also you should have heard of an operating system called Linux (it is probably running on your smartphone and you are waiting for an update).