Automate starting and stopping of multiple containers on single production server



  • I am doing a project for my university where I have the following requirements:

    1. I want to start and stop (docker) containers with different apps
    2. I have a singe (university) server to my disposal
    3. I want the starting and stopping to be somewhat automated using the universities GitLab

    My current idea is the following:
    Users create a new branch on an existing GitLab project. If the branch has some specific format, i.e. Deploy-0x-name a new container is deployed on the server and accessible through the network. If the branch is deleted, the container is also removed from the server. Now I am unsure what tools to use. I was thinking about using Kubernetes, but it seems that is not ideal for a single server setup. At least that's what I read. Also, I don't really need the load balancing between different container instances as there will only be one instance of every application running. Still, I have to manage multiple applications.

    Is there a better alternative for K8s in this situation, or should I use a completely different approach?

    Thank you



  • Jasper -

    I think you want to establish some form of communication between GitLab and your server, in particular, GitLab should be able to initiate events on the server in response to events (changes) in the GitLab repository.

    A common pattern for a solution is to use a webhook -- a feature of GitLab (I assume, I use GitHub) that allows you to instruct GitLab to perform a given action when something happens in GitLab. You can choose which things, for example, you might choose to have GitLab fire the webhook whenever there's a push.

    What happens when the push occurs? You need to pull from the repo, build a new container, upload it to the container repo, then run docker using the new container.

    The webhook is expected to be a URI that refers to a remote server ... in particular, the remove server needs to be listening on the port specified by the URI. The most common port is either the HTTP port 80, or the HTTPS port 443 -- and the reason they are popular is that many systems don't block them, as they do with most other ports. So you need something on your server listening on port 80/443 that will do these steps.

    So the steps needed (pull, build, upload, run) often fall into two phases: "build" and "run", where build includes all the steps needed to deploy a workable application. GitHub offers "github actions" -- I suspect GitLab has something similar -- that give you access to a temporary compute resource for things like running commands e.g. "pull", "compile", and "docker". Or, you could build a basic web server app that ran these commands. Either way, something on the server will need to run docker (or maybe ask it to restart) using the newly built image.

    Could you use Kubernetes for this ... sure ... but as you imply, it's too much for the single task. Learning how to deploy kubernetes is a lot of work. Instead, Google "xyx web server" where xyz is the programing language or environment to find a suitable installable server. Most offer a simple way to integrate system commands and respond to webhooks.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2