Container it! What is Fuel and what does it use Docker for

    While patent wars remain a hidden threat to the OpenStack ecosystem, let's talk about technology that allows you to deploy OpenStack in almost one click. The name of this project was repeatedly found in the posts of our blog, but there was not a single text dedicated specifically to Fuel . Meanwhile, it was this project that greatly simplified the process of deploying OpenStack and made the process of further cloud management less labor-intensive. Of course, you can act the old fashioned way. Using Fuel is optional for working with OpenStack. However, we believe that if a theater starts with a hanger, then OpenStack starts with Fuel. At least Mirantis OpenStack (MOS).

    A few general words about Fuel


    Fuel is an OpenStack deployment tool and subsequent cloud management. It is difficult to name a project that would provide more informational reasons. Now we are telling you that Fuel now uses Docker containers, but we already know about launching plug-in support. But first, let's talk about containers. On the eve of the first Russian Docker-mitap, such a conversation is more than justified.

    Those of you who have already tried OpenStack (we don’t just tell you what it is, but we hope to convince you to spend time experimenting with technology that has attracted our attention two years ago and still does not let it go), they could make sure that manual installation is a laborious, complex and, most importantly, fraught with a lot of mistakes. Fuel is our answer to manual deployment issues. This is an intuitive tool equipped with a web-based user interface, which, in fact, is a control panel for deploying the cloud in a few clicks and further working with it. It is important to note that Fuel simplifies the large-scale (to date, deployment to an environment of 100 nodes has been tested) deployment, testing, and support for OpenStack configurations. As one of the OpenStack ecosystem projects,

    We will return to this development more than once. Now let's talk about Docker.

    Docker: save time and energy


    Starting with MOS 5.0, Mirantis relied on Docker in order to implement a simple and reliable transactional update of Fuel: we raise new containers, check, and if something goes wrong, we return the old ones. Together with simplicity, speed also came. Let's talk about how it was.

    Retrospective


    MOS 5.0

    Our changes allowed the user to re-deploy Fuel in less than 30 seconds without using scripts to return the environment to its original state. Now you can make changes, quickly test them and, if necessary, repeatedly “roll back” back.

    The speed of change was the result of the use of “containers”, the scope of which, in fact, is very wide. The corresponding environment can be created on the basis of a laptop with Mac OS X or Windows (using boot2docker), on QA servers under Ubuntu in the cloud, and also on virtual machines in real data centers based on Red Hat Enterprise Linux.

    To update the Fuel application in Docker, simply remove the old containers and start new ones, saving 1-2 hours that you would need to re-build Fuel ISO and test the changes made.

    MOS 5.1

    In Mirantis OpenStack 5.1, we have reduced the time required to install Fuel on the master node. With virtualized deployment on an SSD, the boot time for images was halved - from 18 minutes to 9 minutes, for containers - from 9 to 8 minutes. When deployed in a lab (on physical servers), the loading time for images in version 5.1 decreased by 20%.

    There was an idea to use temporary file storage (tmpfs) on the master node to reduce installation time, but we found its unreliability in environments with insufficient RAM, which slowed down the process. While our main goal is to gain time.

    But it was possible to increase the stability of Fuel in version 5.1, thanks to the dockerctl utility, which monitors the activity of settings for Fuel during the Docker update, during which hundreds of parameters are transferred in 13 containers. The dockerctl utility is especially important in light of the fact that a large number of matches are established for applications requiring 5-6 parameters from our configuration file (astute.yaml) for each container in order to deploy the application.

    Instead of etcd or other tools that require the use of systemd, we used astute.yaml parameters, left the local file in YAML format and ran Puppet inside the containers to deploy applications on the Fuel master node. We will not necessarily do this in the future, but this method was simpler and less destructive than using other available means. Be that as it may, the local YAML and Puppet file had several drawbacks, for example, they facilitated the establishment of a large number of connections in Docker, which led to a large expenditure of disk resources for each container due to the installation of Puppet and dependent modules. But even so, we use some of the most compact, fully functional images of the Docker OS. The size of the Ubuntu-based Docker image is huge,

    Status quo: MOS 6.0

    We fixed errors in the Fuel settings and implemented log rotation to free up disk space. In addition, when setting the system requirements for 6.0, we took into account the logrotate utility, which by default saves the last five archives (this requires disproportionate disk space, while Docker itself needs disk space for logs that can fill all the free space and crash the file system). This problem does not have an automatic solution, so even with the improvements in log storage made by Mirantis, you still need to monitor the disk capacity, since we cannot predict how much logs you will generate. Despite the fact that logrotate updates the logs every hour, it does not monitor free disk space, but the setting, which would allow to increase the size of the folder with Docker logs, is absent. In fact, the logrotate settings limit the size of a single log file, upon reaching which it is archived. Therefore, even with increased parameters, 30GB should be allocated exclusively for logs (when deployed to 20 nodes). But if you enable debug mode (Debug), the rotation of large files will occur every 10 minutes, and not every hour.

    Other innovations for Docker-based Fuel in Mirantis OpenStack 6.0 include the use of CentOS 6.5 as the operating system for the master node.
    Since CentOS 6.5 does not have a systemd initialization daemon that constantly runs services, Mirantis uses the Supervisor management utility to launch and track Docker containers, as well as launch web applications. “Two in one,” as advertisers like to say.

    In addition, we use a simple try-or-fail scheme to solve
    problems stopping Docker containers that don’t have inherited dependency tracking tools. In our solution, if the Docker containers try to start and then stop due to PostgreSQL or RabbitMQ not yet running, Supervisor waits a few seconds and tries to start the container again, which failed to start until all containers will be launched. This method is much easier to maintain than a complex sequence of putting containers into operation based on priorities or
    dependencies. And, despite the fact that dockerctl has the proper sequence when starting all containers, this sequence only applies to the initial deployment.

    Once again, Fuel is a project of the entire OpenStack ecosystem, so you can use this tool to deploy, test, and support your OpenStack platform. Although, of course, we believe that it is easiest to get it as part of the Mirantis OpenStack distribution . Nevertheless, we are responsible for our distribution and we can guarantee that its use will not damage the reputation of the ecosystem as a whole.

    The first Docker event in Moscow


    Since we ourselves made sure that Docker is a useful tool, we want to share this knowledge. On February 26, from 18:00 to 21:00, Mirantis participates in the first Docker rally in Moscow and invites those who wish to join. Participation is free. You can read more about the event on the Russian OpenStack community website , and register here . For those wishing to participate in the meeting - registration is required. Fabrizio Soppelsa

    will start the meeting - our Fuel Support Engineer, author of the Linux Journal and just an OpenStack enthusiast. He will formulate a brief description of the Docker technology, tell you what are the advantages of using this powerful platform and what makes it popular among developers.

    Next, Matthew Mosesohn is a senior developer at Mirantis. Matthew will talk about the deployment of Docker “Off the Grid”. By the way, it was on his post on our corporate blog devoted to the transition of Fuel to Docker that we relied on when preparing this material.

    Denis Zaitsev , head of the cloud platform and CDN operation group in Yandex, will talk about scaling the Docker Registry; about launching Docker applications in the OpenStack cloud using Murano - Sergey Melikyan, Senior Developer at Mirantis.

    The meeting will be completed by Andrey Vagin , a developer in the Parallels Linux Kernel team. His theme is “Libcontainer: Joining forces under one roof.” Andrey will make a description of the plans and the current status of this task.

    You probably still have (or have) questions. Event is the right place to ask them. But if for some reason you don’t get to the meeting, then write questions in the comments - we will try to call our experts to account.

    Also popular now: