The 11th annual HighLoad++ conference was held from November 7-8 at the Skolkovo Innovation Center. This year, the conference saw 2 700 people in attendance—200 more than last year! Today we’ll be reporting on the highlights and presentations that our team from Selectel saw. Read more
When working with potentially dangerous, unverified, or simply raw software, developers often use sandboxes. These are special environments that isolate or restrict programs and code from accessing data outside the environment. Sandboxes limit the software’s network access, OS interactions, and information from IO devices.
Lately, people have been turning more and more towards containers for launching unverified and non-secure software. Read more
Today we’ll be continuing our containerization blog series with a discussion about runC, a tool for launching containers according to Open Container Initiative (OCI) specifications. The initiative’s mission is to develop a single standard for containerization technology and is supported by such companies as Facebook, Google, Microsoft, Oracle, EMC, and Docker. The OCI Runtime Specifications were published in the summer of 2015.
Modern containerization tools already implement runC. The latest versions of Docker (starting with version 1.11) have been made according to OCI specifications and are built on runC. The libcontainer library, which is essentially a part of runC, has replaced LXC in Docker as of version 1.8.
In this article, we’ll show you how you can create and manage containers using runC.
Today we’d like to continue our blog series on containerization. As our first two articles (1 and 2) were dedicated to theory, this post will focus on one tool and its features: LXD.
LXD (short for Linux Container Daemon) was created by Stéphane Graber, who works for Canonical. His name is well known in the professional community as he is also one of the authors of another popular container solution: LXC. Naturally, LXD is built on LXC, which makes it easier to work with containers and adds a wide range of new abilities.
Today we’ll be continuing our post series on containerization mechanisms. In our last article on containerization, we talked about isolating processes using the namespaces mechanism. For containerization though, isolating resources isn’t enough. If we launch an application in an isolated environment, we should be sure it has been allocated enough resources and not use an inordinate amount, interrupting the rest of the system. For this task, the Linux kernel has a special mechanism, cgroups (short for control groups), which we will talk about today.
Linux container solutions have gained quite a bit of popularity over the last few years. A lot of people have written or spoken about how containers can be used and what for, but little attention has been paid to the mechanisms behind containerization.
All containerization tools, like Docker, LXC, or systemd-nspawn, are built on two Linux kernel subsystems: namespaces and cgroups. In this article, we’ll be taking an in-depth look at namespaces.
Containerization has become an increasingly relevant topic. There are already thousands, if not tens of thousands, of articles and posts written about popular solutions like LXC and Docker.
In today’s article, we’d like to discuss systemd-nspawn, a systemd component for creating isolated environments. Systemd is already a standard in the world of Linux and in light of this, it wouldn’t be unfounded to suggest that the potential for systemd-nspawn will significantly expand in the near future. For this reason, we think now would be a good time to better acquaint ourselves with this tool.