I participate in open source-community more than 5 years, I am engaged in network technologies, PaaS-infrastructure and technologies of containerization. Participation in such projects as OpenFlow/SDN, OpenStack went over with variable success, but Docker objectively collects an attention maximum from technical community now.
Developers pay much attention to the built-in architecture, journalizing, monitoring, migration of data, networks and start in containers of the processes saving internal state (stateful services) worldwide. Before it is deeper to plunge into a subject of persistence-volumes and to show results of work of my command, I want to select several hot topics of conference and community in general.
Use of Docker in the prodakshena became one of the subjects DockerCon 2015. Depending on the one whom you ask about experience with Docker and about that how exactly it was used, answers will be different. Production with use of containers with microservices can be "hell" as Brian Kentrill was expressed (if you did not see Brian's performance about Unix-philosophy and debugging at an execution stage, I very much recommend to look at any videos with its reports, especially from the O'Reilly conference which took place on the eve of DockerCon). But, on the other hand, it helps to separate applications into limited domains with high degree of controllability, and design teams have an opportunity to effectively carry out process of CI/CD of debugging/delivery/expansion. The open code Netflix on github is confirmation to it, and Endrian Kokroft (Andrian Cockcroft) rather deeply rummaged in a subject. Also you can look at my post about microservices which will help you to understand a context.
Whether Docker for a prodashen is so good? Below I will describe the moments about which you need to know before use of Docker in the prodakshena. There is also a wish to add that each of points is a separate big subject DockerCon'a.
Interaction of the Docker company and startup of Socketplane poured out in a possibility of use in projects of the Libnetwork technology which allows to connect Docker-demons from different hosts that simplifies to the container transfer of IP traffic over the data link layer of a network. Libnetwork is supported from the outside of the main demon of Docker, does not depend on implementation of a network and that the most important, hides from the user of a detail of implementation, allowing all system "it is simple to work".
I communicated with Eric Vindish from Docker who told that the key attention as any vulnerability in it would mean threat for the container was always paid to safety of the Docker engine. Large-scale works on improvement of a code in a security subsystem are conducted, and also other tools on the basis of AppArmor and SELinux are used. It is very curious how the security subsystem of Docker will reveal together with such projects as VMWare Lightwave.
Journalizing, monitoring, controllability
Containers are, of course, abruptly, but, having started at the same time one thousand or ten thousand of containers, realize need for the tool which would allow to debug, monitor and manage them effectively. And it seems that we are waited by a solution. Project Orca announced by the founder of Docker Solomon Hayks is aimed at the connection Docker Engine, Docker Swarm, GUI, Docker Compose, and also tools for safety, installation, expansion and configuring. Of course, it is not obligatory to start Docker through Orca, but it would be exciting to have a method to receive all above-mentioned, without losing in the speed and controllability. Other tools (loggly, cadvisor, ruzit, datalog, log entries) compete for the place in this list, and it is simply excellent!
Docker gives an initiative to community, declaring that it wants to be the expanded tool allowing different plug-ins to work with a network, authentication, data storages. At the moment there is VMWare Lightwave for authentication and EMC ScaleIO for a persistention of storage. Not so badly, considering that the Docker is only two years old!
Persistent-services with saving of internal state
EMS and ClusterHQ did together a great job, having created open source-проект Flocker. It allows to manage volumes of containers and provides migration of data and high availability of volumes in situations when it is necessary to recover konteynerizovanny applications.
Also great interest at conference caused the announcement of expansions of native volumes Docker'a. Despite the experimental status, starting with the version 1.7.x these expansions provide different options of management of services with saving of internal state. Flocker in itself can work with expansions of Docker-volumes by means of volume-driver=flocker flag if to use Flocker-Docker a plug-in.
The publication on GitHub of source codes of the drivers allowing to work with EMC ScaleIO and EMC XtremIO became an interaction result with ClusterHQ. In Pivotal laboratory in San Francisco we demonstrated all opportunities of drivers. As a result the people were going to look at demos behind beer and conversations in an informal situation. According to this link the demo of ScaleIO which we showed at the meeting devoted to work of Flocker + ScaleIO unrolled on Amazon AWS with use of MEAN application stack into which loaded data with Twitter and which placed in MongoDB lies. Slides from a meeting are also available here.
Not all guests of DockerCon had enough places, many listeners stood or sat on a floor all session. We hoped that we will have slightly more time that children with notebooks had an opportunity to hack our demo, but there were obviously not enough 40 minutes which are released to us. Made everything that could!
Through native Go-implementation under the name RexRay, EMC integrates ways of management of persistence-volumes, but without automatic migration of data which is made by Flocker. Possibilities of RexRay are very wide, for example, you can use several backends at the same time, say, of EC2 EBS + EMC ScaleIO.
In the whole persistence and containers continue to remain actual, and to that there are reasons. At the beginning, the processes which are not saving internal a status (stateless) and methodology of twelve factors were in a trend. But all this is torn off from reality. The community understands that statuses exist, and start of stateful-processes in containers, for example, of databases, is really actual for the world of microservices. Each container is in some status even if it is "stateless" - a status. For example, in memory there can be such statuses as the performed applications and open sockets with which it is necessary to work in certain cases, for example, at migrations of data "on the fly".
Data become extremely important in a container environment. In process of a mapping of loads of architecture of the container there is a need of adding of coordination of data. Integrity and availability will be necessary for services which save internal state. Add to all this also industrial SHD. At conference different solutions of this problem, here some of them were proposed:
• Crate.io. Scalable distributed database which is established on an application server.
• ClusterHQ/Flocker. The container Open source-volume manager allowing to containerize databases and other processes with saving of a status, and also to move them without worrying for backend.
• Red Hat declared integration of persistent-storage for containers with use of RHS (Red Hat Storage).
• Nutanix told about Volume API which will help with ensuring persistence of containers on their platform.
• Portworx. It seems, it is a new startup which will compete with ClusterHQ. In the announcement it is said about how "part" of their platform will become open source.
• Support of Kubernetes for storages. Kubernetes updated documentation on GitHub which reflects a possibility of use of Google Cloud persistant disk with k8s.
Generally, it was the excellent DockerCon complete of cheerful events, excellent children and the innovation technologies. I hope, we will meet you in Barcelona in November!
This article is a translation of the original post at habrahabr.ru/post/263055/
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here: firstname.lastname@example.org.
We believe that the knowledge, which is available at the most popular Russian IT blog habrahabr.ru, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.