DockStation Why we decided to make this project

    Working with Docker is not an easy task. In this article I would like to tell you what prompted us to create the DockStation project and what we have already implemented at the moment.

    Start


    I have been working as a developer for more than 8 years, and it has always been a pain for me to set up the dev environment for development when switching to another OS or changing the working machine.

    Sooner or later, many developers come to the border when it becomes necessary to create a single and autonomous development environment. Such an environment can be easily transferred from one machine to another, disabled with one click, share it. With this in mind, all roads led to Vagrant.

    However, for the past two years, there has been a certain unknown and incomprehensible thing to me that seemed to fit my needs - Docker. This project is often awarded prizes, and some even call it the best of what has been created over the past 20 years. However, even despite the fact that at night I had a little DevOps-il (nobody sees it yet), for me all these “isolated containers” were a dark forest. Nevertheless, I decided to sort out this interesting thing.

    Docker: how to manage all this?


    The first steps in the development were not very simple, but at some points the guys from the dev.by community helped me in the Slack chat.

    Although Docker is positioning itself as a deployment tool, I realized that it fully meets all my requirements for a development environment.

    Having spent about a week studying the documentation, I understood the philosophy itself and how to work with this wonderful tool. Only one thing confused - kilometer-long CLI commands that needed to be run every time to start the container. Apparently, I was not the only one in such trouble: the guys had another Docker Compose tool in their arsenal, which allowed them to save all these kilometer commands into a single configuration file. And it seems - you can rejoice, but reality, as usual, turns out to be cruel.

    Having collected and transferred my personal and working working projects and having received as a result of more than fifty containers, I came across 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. The search began for an application that would help manage this whole thing.

    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 the container without any questions, make many manipulations with it, such as viewing logs or quick access to the container.

    But this did not solve my problem: to parse and group a bunch of containers from my projects. And it didn’t solve any global issues, it only helped a little to work with containers and monitor their condition. Then I looked at Rancher, but again not that: this tool is designed and sharpened for deployment, and for the developer it is not quite suitable. Similar tools such as Shipyard and Portainer were found, but they were all just slightly more elaborate versions of Kitematic. Well, since there is no solution to the desired problem, we will do it ourselves.

    DockStation: more than six months of hard work


    So, starting from the usual idea of ​​a banal grouping of containers by projects, there was a desire to make your product. It would be very difficult to pull one such project, the development of "one person" would take a lot of time. In December 2016, I came up with this idea and with a proposal for 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 great startup gurus that you need to start already at the Hello World stage and, having in your hands just an idea, run to investors for money on MVP. After six months of painstaking and hard work, the project was released.

    The project was originally based on the following principles:

    1. You don’t have to learn tons of documentation initially to get started with Docker and Docker Compose. Although the philosophy itself and the principles still need to understand.
    2. The application should be native, so that you don’t have to dance with a tambourine for easy launch (Kitematic liked the concept more).
    3. Backward compatibility. All generated projects should be launched both in the application and through the CLI. Similarly, the availability of the ability to import third-party Docker Compose projects into the application.
    4. Everything that can be transferred to the GUI as much as possible.

    Total, looking around at the last 10 months of work.

    What do we know today


    1. 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.
      • Parse Docker commands (beta). For those who have always used only docker run commands, it is possible to import a project, simply by entering these commands, they will be transferred to the Compose project.

      image
      • Creating a project from scratch is just a click away.
        image


    2. Monitoring projects and services.
      At any time, you can find out if the project is working, and if not, which of the services does not work. Using logs, find out what the problem is. Full-text log search has been implemented.
      image
    3. 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 information on containers.
      • Changing the version of the image, port binding, redefining and assigning environment variables, and much much more is needed to configure and manage the project.

      image
    4. Project Settings.
      Frequently used project settings can be changed through the interface. All changes will be immediately recorded in the docker-compose config. If something needs to be done custom, then without problems you can edit the compose config manually and everything will work.
      image
    5. Work with both local Docker and remote.
      Implemented a system for creating and working with remote connections to Docker, which makes it possible to fully manage remote containers. A very strong feature is the ability to connect to Docker via SSH, which will allow avoiding a lot of work on reconfiguring Docker to open an external port and configure security.
      image
      image
      image
      image
      image
    6. Statistics on the consumption of resources of both projects as a whole and individual containers.
      Docker has a very weak spot 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 issue hangs, maybe soon it will appear: https://github.com/docker/compose/issues/1197 )
      image
      image
    7. Real-time resource monitoring.
      Very similar to the task manager, only for containers.
      image
    8. Working with Docker Machine
      Full implementation of Docker Machine with driver support:
      VirtualBox , VMWare , Hyper-V
      image
    9. Working with the Docker Hub
      You can very easily and simply work with images from the Docker Hub. Search and configure images.
      image
      image
    10. Pleasant extras.
      • Since IP containers change upon restart, managing a project using a local host name is not quite easy. We solved this problem: when changing the IP container, the current host entry in / etc / hosts will be installed.
      • Implemented support for Override configs.

      image

    Current results and results

    Today, our main merit is that we released the product. After leaving work for a full-time immersion in the project, spending a total of more than 10 months of personal time and some amount of his money, without external support, they released the project into life and continue to develop it. Since our main task was to work on the project, we did not attend any start-up parties, events and other events, so we do not have badges, marks or awards from experts. But now more than 1000 developers use our application per month, we have hundreds of positive reviews and suggestions, and this inspires us to create more.

    Web
    GitHub (the project is not OpenSource, but there are all communications)

    Also popular now: