ATIX AG
  • Services
    • Consulting
      • Linux Platform Operations​
      • Infrastructure Automation
      • Container Platforms and Cloud
      • DevOps Processes, Tooling and Culture
      • Cloud Native Software Development
    • Products
      • orcharhino
        • About orcharhino
        • Support
        • orcharhino operation
      • Hangar
        • About Hangar
        • Hangar Roadmap
        • Hangar Community
    • Technologies
      • Ansible
      • Docker
      • Foreman
      • GitLab
      • Istio
      • Kubernetes
      • Linux Distributions
      • OpenShift
      • Puppet
      • OpenVox
      • Rancher
      • Rundeck
      • SaltStack
      • SUSE Manager
      • Terraform
  • Trainings
    • Ansible Training
    • Container Training
    • Docker Training
    • Git Training
    • Go Training (Golang)
    • Istio Training
    • Kubernetes Training
    • OpenShift Training
    • orcharhino Training
    • Puppet Trainings
    • Terraform Training
  • Events
    • Webinars
  • Blog
  • Company
    • About Us
    • References
    • Corporate values
    • Social engagement
    • Newsroom
    • Newsletter
    • Contact us
  • Career
  • Search
  • Menu Menu

Rancher: Conducting a container pack

Rancher was developed to manage containers clearly and easily, especially on clusters. Rancher was primarily developed for Docker and forms a cluster of several servers (=hosts) via Cattle on which Docker runs, but Docker Swarm, Kubernetes and Mesos are also supported.

However, this article will not go into these container environments any further, but will instead focus on the orchestration of Docker with Rancher.

The Rancher server for administration runs itself in a Docker container and is started like a normal Docker container. The servers (= hosts) can then be connected to the server via the Rancher agent, whereby the Rancher agents also consist of a Docker container. The Rancher server can be easily started with the following command and can then be reached under the corresponding server IP and, in this case, port 80:

sudo docker run -d --restart=unless-stopped -p 80:8080 rancher/server

Once the Rancher server has downloaded and started its container image, it usually takes less than a minute for the web interface to be accessible under the server’s IP. The hosts can then be added. To do this, you can copy the corresponding command from the graphical user interface, as a server token is required in addition to the server IP in order to subsequently assign the host to the correct environment in Rancher and gain access. The command for this then has the following structure:

sudo docker run -d --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v1.1.3 /v1/scripts/

As soon as the corresponding Rancher agent container has been downloaded and started, the new host appears in the Rancher interface after a few seconds and also recognizes all Docker containers already running on it. Docker hosts with different operating systems can also be combined – the only requirement is that the hosts should have at least 1 GB of RAM available and Docker version 1.10.3 or higher.

Scaling of containers

Similar to Docker Swarm, Rancher offers the option of starting containers multiple times and utilizing them evenly via a load balancer (via HAProxy). This also allows the number of containers to be adjusted with just a few clicks in order to react to temporarily changing requirements.

Rancher also comes with two forms of health checks. These health checks check at regular intervals whether the container is still responding and, depending on the configuration, if a container fails, a new container is started in the cluster to replace the failed one. In combination with many hosts, a high-availability system can thus be configured in which isolated server failures can be intercepted and the services of the containers maintained.

Rolling upgrades of the containers

As containers usually also have to be adapted by updates, Rancher offers the option of upgrading containers in defined steps. In some cases, it is also possible to start the new version while the old version is still running. As soon as the new version of a container has been successfully started, the upgrade can be confirmed and the container with the old version is stopped and deleted. If the new version does not start or the upgrade is aborted, the old version is automatically restarted if it has been terminated up to that point. This can greatly reduce or even avoid downtimes during upgrades.

User-friendly web GUI

The big advantage over Docker Swarm is Rancher’s graphical web interface, which can be used to manage the entire cluster. Despite the web interface, the possibility of administration via the command line remains, but almost all tasks can be solved more quickly and easily via the GUI and there is a much better overview of the running processes, their status and the utilization of the containers and servers.

Various user administrations can be set up for access to the Rancher interface. Rancher supports OpenLDAP and GitHub, for example, but locally created user accounts and groups are also possible. Different cluster environments can also be set up and the corresponding users can be granted only limited or read-only authorizations. This means that Rancher can be used by several user groups at the same time, but not every user can start or stop containers at will.

Rancher can therefore be used to manage a large cluster with a large number of containers while remaining clearly organized and the responsibilities can be distributed to different users, which is not so easy with Docker Swarm.

This is part 4 of a series of blog posts on the topic of Docker/Rancher.

Part 1 provides an overview of Docker and container environments

Part 2 explains the functions of a Docker registry and docker-compose

Part 3 introduces Docker Swarm with a Docker environment distributed across multiple hosts

Part 4 shows Rancher as an orchestration tool for Docker (and other container environments)

Part 5 contains brief information on the Rancher functions of a catalog and rancher-compose

You might also like
prometheus monitoring atix blogPrometheus Monitoring—Fix It before It Breaks
kubeflow ATIX blogSelenium IDE – Automated testing of web applications with a browser
DevOps Culture “without Bullshit”
tracing all the thingsTrace All the Things
kubeflow ATIX blogDocker containers – a lightweight alternative to virtualization
kubeflow ATIX blogKubeflow at Home: AI and Kubernetes outside of Google & Co.
ATIX-Crew
+ postsBio

Der ATIX-Crew besteht aus Leuten, die in unterschiedlichen Bereichen tätig sind: Consulting, Development/Engineering, Support, Vertrieb und Marketing.

  • ATIX-Crew
    https://atix.de/en/blog/author/atix-crew/
    Foreman Birthday Party 2024
  • ATIX-Crew
    https://atix.de/en/blog/author/atix-crew/
    CrewDay 2024
  • ATIX-Crew
    https://atix.de/en/blog/author/atix-crew/
    Navigating the XZ Security Vulnerability: A Comprehensive Guide
  • ATIX-Crew
    https://atix.de/en/blog/author/atix-crew/
    Automating Kafka with Ansible
Expertise that Drives your IT Forward

🔔 Technology. Trends. Dates.
Stay up to date with the latest IT developments and upcoming events. Subscribe now and stay informed.
👉 Subscribe to our newsletter »

🎓 Webinars – Live & On-Demand
Knowledge on your schedule. Practical insights on DevOps, Open Source & IT automation.
👉 Explore now »

ISO Certified Certificate
Newsletter
Never miss anything again. Sign up for the ATIX newsletter!
Sign up now
Blog
  • Blog Start Page
  • ATIX Insights
  • Cloud Native
  • Container Plattformen und Cloud
  • DevOps
  • Hangar
  • Infrastructure Automation
  • Linux Platform Operations
  • orcharhino
Privacy & Legal

Privacy Policy

Imprint

Terms and Conditions

B2B

Twitter     Facebook    LinkedIn    Xing     Youtube     mastodon=

© Copyright – ATIX AG

Scroll to top