DockStation. Why we decided to make this project
Working with Docker is not an easy task. In this article I would like to tell what pushed us with the creation of the DockStation project and what we have already implemented at the moment.
I have been working as a developer for more than 8 years, and for me the dev setting for development has always been a pain when switching to another OS or changing the working machine.
Sooner or later, many developers come to the border when there is a need to create a single and autonomous environment for development. Such an environment can be transferred from one machine to another without any problems, disconnected with one click, and shared. Given this need, all roads lead to Vagrant.
However, the last two years, there was some kind of unknown and incomprehensible for me thing that seemed to fit my needs - Docker. This project is often honored with awards and prizes, and some even call it the best of what has been created in the last 20 years. However, even though at night I was a bit of a DevOps-il (no one sees it yet), for me all these “insulated containers” were a dark forest. Nevertheless, I decided to understand this interesting thing.
')
The first steps in mastering were not entirely simple, but in some moments I was helped by the guys from the dev.by community in Slack chat.
Although Docker positions itself as a deployment tool, I realized that it fully meets all my requirements for the development environment.
Having spent about a week studying documentation, I understood the very philosophy and how to work with this wonderful tool. Only one thing confused me — the kilometer-long CLI commands that needed to be launched each time to launch the container. Apparently, I was not alone in such trouble: the guys had another Docker Compose tool in the arsenal, which allowed saving all these kilometer commands into a single configuration file. And it seems that one can rejoice, but the reality, as usual, turns out to be cruel.
Having collected and transferred my personal and work projects and received more than fifty containers in total, I was confronted with the question: “How to manage all this?”. I know from my own experience: if there is something console, then there must be something “mouse-usable” on the GUI. Began the search for an application that would help manage all this business.
The first thing I came across was Kitematic, a Docker GUI application that allows you to manipulate containers.
You can stop, restart, delete a container, perform many manipulations with it, such as viewing logs or quick access to the container, without question.
But this did not solve my problem: to disassemble and group a bunch of containers from my projects. Yes, and it did not solve any global issues, only slightly helped working with containers and monitoring their condition. Then I looked at Rancher, but again, not that: this tool is designed and tailored for deployment, and it’s not quite suitable for a developer. Similar tools like Shipyard and Portainer were found, but all of them were only slightly more elaborate Kitematic variants. Well, since there is no solution for the desired task, we will make a decision with our own hands.
So, starting from the usual idea of ​​banal grouping of containers for projects, there was a desire to make your product. One such project would be very difficult, the development of “one person” would take a lot of time. In December 2016, I came up with this idea and with the proposal of joint development to my friend Pavel Lozko. He worked with Docker, so he quickly understood the general meaning of the project and agreed to participate.
Two months later, I switched to full-time work on the project.
As a result, we violated all the rules, ignored the advice of the great start-up gurus that we should start at the Hello World stage and, having only the idea, run to the investors for MVP money. After six months of painstaking and hard work, the project came out.
The project was originally based on principles:
Total, looking around for the last 10 months of work.
Current results and results
Today, our main merit is that we have released a product. Having left work for a full time immersion into a project, having spent more than 10 months of personal time and a certain amount of money, we released the project to life and continue to develop it. Since the main task was to work on the project, we didn’t attend any start-ups, events and other events, so we don’t have any badges, marks and awards from the experts. But now our application is used by more than 1000 developers per month, we have hundreds of positive feedback and suggestions, and this inspires us to create further.
Web
GitHub (the project is not OpenSource, but there are all communications)
Start
I have been working as a developer for more than 8 years, and for me the dev setting for development has always been a pain when switching to another OS or changing the working machine.
Sooner or later, many developers come to the border when there is a need to create a single and autonomous environment for development. Such an environment can be transferred from one machine to another without any problems, disconnected with one click, and shared. Given this need, all roads lead to Vagrant.
However, the last two years, there was some kind of unknown and incomprehensible for me thing that seemed to fit my needs - Docker. This project is often honored with awards and prizes, and some even call it the best of what has been created in the last 20 years. However, even though at night I was a bit of a DevOps-il (no one sees it yet), for me all these “insulated containers” were a dark forest. Nevertheless, I decided to understand this interesting thing.
')
Docker: how to manage all this?
The first steps in mastering were not entirely simple, but in some moments I was helped by the guys from the dev.by community in Slack chat.
Although Docker positions itself as a deployment tool, I realized that it fully meets all my requirements for the development environment.
Having spent about a week studying documentation, I understood the very philosophy and how to work with this wonderful tool. Only one thing confused me — the kilometer-long CLI commands that needed to be launched each time to launch the container. Apparently, I was not alone in such trouble: the guys had another Docker Compose tool in the arsenal, which allowed saving all these kilometer commands into a single configuration file. And it seems that one can rejoice, but the reality, as usual, turns out to be cruel.
Having collected and transferred my personal and work projects and received more than fifty containers in total, I was confronted with the question: “How to manage all this?”. I know from my own experience: if there is something console, then there must be something “mouse-usable” on the GUI. Began the search for an application that would help manage all this business.
Competitors "do not solve global issues"
The first thing I came across was Kitematic, a Docker GUI application that allows you to manipulate containers.
You can stop, restart, delete a container, perform many manipulations with it, such as viewing logs or quick access to the container, without question.
But this did not solve my problem: to disassemble and group a bunch of containers from my projects. Yes, and it did not solve any global issues, only slightly helped working with containers and monitoring their condition. Then I looked at Rancher, but again, not that: this tool is designed and tailored for deployment, and it’s not quite suitable for a developer. Similar tools like Shipyard and Portainer were found, but all of them were only slightly more elaborate Kitematic variants. Well, since there is no solution for the desired task, we will make a decision with our own hands.
DockStation: more than half a year of hard work
So, starting from the usual idea of ​​banal grouping of containers for projects, there was a desire to make your product. One such project would be very difficult, the development of “one person” would take a lot of time. In December 2016, I came up with this idea and with the proposal of joint development to my friend Pavel Lozko. He worked with Docker, so he quickly understood the general meaning of the project and agreed to participate.
Two months later, I switched to full-time work on the project.
As a result, we violated all the rules, ignored the advice of the great start-up gurus that we should start at the Hello World stage and, having only the idea, run to the investors for MVP money. After six months of painstaking and hard work, the project came out.
The project was originally based on principles:
- It’s not necessary to learn tons of documentation at the beginning to get started with Docker and Docker Compose. Although the philosophy itself and the principles still need to be understood.
- The application must be native, so that you do not have to dance with a tambourine for a simple launch (the Kitematic concept was liked more).
- Backward compatibility. All generated projects must be launched both in the application and through the CLI. Similar to the possibility of importing third-party Docker Compose projects into the application.
- Everything that can be maximally transferred to the GUI.
Total, looking around for the last 10 months of work.
What we can do today
- Quickly create projects on the fly.
- Import existing projects by simply specifying the path to the directory in which the docker-compose.yml configuration file is located.
- Parsit Docker commands (beta). For those who have always used only docker run commands, it is possible to import a project by simply typing these commands, they will be transferred to the Compose project.
- To create a project from scratch is just one click away.
- Monitoring projects and services.
At any time you can find out if the project is working, and if not, which of the services is not working. With the help of logs find what the problem is. Implemented full-text search by logs.
- Service and container management.
- Quick start, restart, stop services and all containers associated with them.
- Fast cleaning service containers.
- Access inside containers with one click.
- Getting all the information on containers.
- Changing the version of the image, port binding, redefinition and assignment of environment variables and much more that is necessary for setting up and managing the project.
- Project settings.
Frequently used project settings can be changed via the interface. All changes will be immediately recorded in the docker-compose config. If you need to do something custom, then without any problems you can edit the compose config manually and everything will work.
- Work with both local Docker and remote.
Implemented a system for creating and working with remote connections to Docker, which allows you to fully manage remote containers. A very strong feature is the ability to connect to Docker via SSH, which will allow you to avoid a lot of work on reconfiguring Docker for opening an external port and configuring security.
- Statistics of resource consumption of both projects as a whole and individual containers.
In Docker, there is a very weak point in terms of monitoring resources for Compose projects in general. It allows you to monitor only the resources of individual containers. Well, we fixed it. (by the way, the issue hangs, perhaps soon it will appear: https://github.com/docker/compose/issues/1197 )
- Real-time resource monitoring.
Very similar to the task manager, only for containers.
- Work with Docker Machine
The full-featured work with Docker Machine with driver support has been implemented:
VirtualBox , VMWare , Hyper-V
- Work with Docker Hub
You can very easily and simply work with images from the Docker Hub. Search and configure images.
- Nice additions.
- Since container IPs change when restarted, managing a project using the local host name becomes not entirely simple. We solved this problem: when changing the IP container, the actual host entry in / etc / hosts will be set.
- Implemented support for Override configs.
- Since container IPs change when restarted, managing a project using the local host name becomes not entirely simple. We solved this problem: when changing the IP container, the actual host entry in / etc / hosts will be set.
Current results and results
Today, our main merit is that we have released a product. Having left work for a full time immersion into a project, having spent more than 10 months of personal time and a certain amount of money, we released the project to life and continue to develop it. Since the main task was to work on the project, we didn’t attend any start-ups, events and other events, so we don’t have any badges, marks and awards from the experts. But now our application is used by more than 1000 developers per month, we have hundreds of positive feedback and suggestions, and this inspires us to create further.
Web
GitHub (the project is not OpenSource, but there are all communications)
Source: https://habr.com/ru/post/340830/
All Articles