Select Page

NETWAYS Blog

4 Dinge, die neu sind bei NWS Kubernetes

Getreu dem Motto: “you answered – we listened” hat unser NWS-Platform-Team diese Woche für unsere Kunden neue Optionen zum Erstellen von Managed Kubernetes Clustern eingeführt, die im folgenden kurz erläutert und vorgestellt werden:

 

1. Neue Kubernetes Versionen

Das neueste Kubernetes Major Release 1.21 ist jetzt – einen Monat nach dem offiziellem Release – auch für NWS Kunden einsatzbereit! Änderungen und Neuigkeiten findet man wie gewohnt im offiziellen Changelog.

Neben der aktuellen Version 1.21 gibt es weiterhin die Möglichkeit, Kubernetes Cluster in den Versionen 1.18, 1.19 und 1.20 zu erstellen. Die Version 1.18 ist  jedoch bereits “End of Life” und deswegen nicht mehr unbedingt zu empfehlen.

 

Kubernetes Cluster erstellen

2. Private Cluster

Beim Erstellen eines Clusters kann man ab sofort zwischen einem “Private” oder einem “Public” Cluster wählen. Damit wird die Erreichbarkeit der Kubernetes-API des Clusters gesteuert. Ein privater Cluster hat nur eine interne IP und keine weitere öffentliche Floating-IP und ist dementsprechend nur von innerhalb der Kundenumgebung (OpenStack- oder Kubernetes-Projekt) erreichbar oder via VPN.

 

3. Individuelle Subnetze

Ebenso kann beim Erstellen eines neuen Clusters das Subnetz – in dem die Nodes kommunizieren – frei gewählt werden. Das ist insbesondere dann hilfreich, wenn man einen privaten Kubernetes Cluster per VPN mit einem bestehenden Firmennetz verbindet!

 

4. Rotate CA

Das Rotieren der Kubernetes CA kann jetzt über die Web-Oberfläche angestoßen werden. Es wird eine neue Cluster CA erzeugt und entsprechend neue Schlüssel und Zertifikate für Service-Accounts und Kubernetes-Nodes verteilt. Die bestehende kubeconfig-Datei des Administrators muss dann durch eine neue ausgetauscht werden.

 

Kubernetes Tutorials

Wer sich nochmal eine genaue Anleitung, wie man schnell und einfach sein Managed Kubernetes bei NWS aufsetzt, durchlesen möchte, der findet diese und viele weitere Kubernetes Tutorials auf unserer Website. Gerne mal vorbeischauen!

Sebastian Saemann
Sebastian Saemann
CEO Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

How To NWS: Infrastructure as a Service mit OpenStack

This entry is part 4 of 7 in the series How To NWS

Im letzten Blog habe ich mit unserer Software as a Service Plattform den ersten Teil unseres Portfolios vorgestellt. Hier kann sich jeder standardisierte Apps schnell und einfach selber anstarten. Manchmal lassen sich die Anforderungen unserer Kunden aber nicht über die Apps abdecken, da beispielsweise per Default deaktivierte Funktionen benötigt werden oder wir schlichtweg den benötigten Dienst nicht in unserem App-Portfolio haben. Wer individuelle Anforderungen an seine IT Umgebung hat, der ist in unserem Infrastructure as a Service Bereich richtig.

Abhängig davon ob virtuelle Maschinen oder Container zu orchestrieren sind, können sich unsere Kunden zwischen OpenStack und Kubernetes entscheiden.

In dem heutigen Blog möchte ich unser OpenStack Angebot vorstellen:

Bei OpenStack handelt es sich um ein OpenSource-Projekt, das von zahlreichen namenhaften Unternehmen (Suse, Linux, HP etc.) unterstützt und ständig weiterentwickelt wird. Ursprünglich ins Leben gerufen wurde es von Rackspace und der NASA. Es setzt sich aus einzelnen Softwareelementen (Nova, Keystone, Glance, Neutron, Cinder, Swift, Horizon) zusammen, mit denen man im Verbund eine Cloud-Plattform erstellt.  Es handelt sich also um ein Cloud-Betriebssystem mit einer Vielzahl an Funktionen. Eine wesentliche Voraussetzung für das Cloud-Computing ist die Virtualisierung, das heißt die Trennung der Stack-Ebenen. Das ermöglicht, dass mehrere Betriebssystem-Instanzen auf der selben Hardwareeinheit betrieben werden können. Auch der Zugang zu Speicher und Netzwerken wird virtualisiert. Im Endeffekt können so sämtliche Bausteine eines Rechners durch Schnittstellen und Konfigurationen referenziert werden. Man erhält eine flexibel änderbare und skalierbare Struktur.

Dadurch, dass OpenStack von Cloud-Computing-Experten aus aller Welt – also großen Konzernen (z.B. Telekom), mittelständischen Unternehmen (wie uns) und kleinen, hippen Startups – genutzt und ständig weiterentwickelt wird, bleibt gewährleistet, dass das Projekt ständig auf der Höhe der Zeit und den Ansprüchen des Marktes gewachsen ist. Ein weiterer, großer Vorteil gegenüber den großen, bekannten Cloud-Anbietern ist der Wegfall des Vendor Lock-in. Es sind ausschließlich standardisierte Schnittstellen im Einsatz. So kannst Du bei Bedarf Deine Unternehmensdaten unkompliziert migrieren, was einen Anbieterwechsel jederzeit möglich macht.

Mit unserem OpenStack kannst du Server und Netzwerke schnell und einfach starten. Virtuelle Maschinen, Speicher und Netzwerke lassen sich mühelos einrichten und vor allem auch jederzeit dynamisch an sich verändernde Anforderungen anpassen. Dabei kann bei den Virtuellen Maschinen aus einem Pool von vorgefertigten Images für alle gängigen Betriebssysteme mit unterschiedlichen Sizing-Varianten gewählt werden. Diese lassen sich ganz einfach per Knopfdruck starten. Sollte das gewünschte Sizing nicht dabei sein, kann man sich die Ausstattung der VM selbstverständlich auch individuell nach seinen Vorstellungen anlegen. In Puncto Sicherheit kann man mit Methoden wie Firewalls, Verschlüsselung und Dienstrichtlinien festlegen, wer wie auf welchen Server zugreifen kann und beim Thema Backup kann man frei entscheiden, ob Snaphots oder Images in welcher, freiwählbaren Rotation gesichert werden sollen. Alle Daten liegen 3-fach redundant gesichert auf unseren Ceph-Cluster, der sich über unsere beiden DIN ISO 27001 zertifizierten Rechenzentren verteilt.

So lässt sich das OpenStack Projekt bequem und übersichtlich über unser Dashboard zusammenstellen und einrichten. Der Punkt der Übersichtlichkeit führt mich auch gleich zu einem weiteren wichtigen Vorteil unseres OpenStack Angebots: Bezüglich der Kosten können wir ein maximales Maß an Transparenz bereitstellen. Es gibt keine undurchsichtigen Pauschalen und Gesamtpakete. Alle verwendeten Ressourcen werden stundengenau abgerechnet. Über unseren Cost Explorer siehst Du die für den Monat bereits entstanden Kosten und bekommst anhand der aktuell genutzten Ressourcen auch gleich eine Hochrechnung über die voraussichtliche Summe am Monatsende. Man hat die Kosten also zu jeder Zeit im Blick und  kann im Bedarfsfall sofort reagieren. Das liegt auch daran, dass es keinerlei Vertragslaufzeiten gibt. Wird eine VM nicht mehr benötigt, kann man diese umgehend runterfahren. Am Monatsende zahlst Du dann nur den Betrag, der bis zu der Abschaltung entstanden ist. Das gibt Dir absolute Flexibilität in beide Richtungen – Du kannst schnell wachsen und, wenn nötig, Dein Setup auch direkt verkleinern.

Und natürlich haben wir auch hier technische Unterstützung im Angebot. All diejenigen, die ihre Zeit nicht mit der Einrichtung und Wartung ihrer IT-Infrastruktur verbringen wollen, können unseren MyEngineer-Service dazu buchen. Auf diesen werde ich aber erst in dem übernächsten Blogartikel genauer eingehen.

Hier geht es zu unserer OpenStack Seite: https://nws.netways.de/de/cloud/

Hier findest du unsere Preisliste: https://nws.netways.de/de/preise/

Und hier findest Du Tutorials und Webinare zu OpenStack: https://nws.netways.de/de/

Stefan Schneider
Stefan Schneider
Account Manager

Vor seiner Zeit bei NETWAYS hat Stefan als Projektmanager in einer Nürnberger Agentur dabei geholfen, Werbeprojekte auf die Straße zu bringen. Seit Juni 2017 ist er nun stolzes Mitglied der NETWAYS-Crew. Hier war er zuerst der Ansprechpartner für unserer Schulungen und kümmert sich aktuell um alle Anfragen rund um unser Hostingangebot. Die Freizeit vertreibt sich Stefan am liebsten mit Sport. Vom Joggen über Slacklining bis zum PennyBoard fahren ist er für alles zu haben.

Einfacher als gedacht: Openstack + Vagrant

Vagrant-LogoOpenstack-LogoVermutlich haben sich bei fast allen durch Covid-19 die Prioritäten verschoben, bei mir kam sehr schnell zu dem Thema “Ausbildung trotz 100% Home-Office aufrecht erhalten” noch ein weiteres dazu. Und zwar das Thema Online-Schulungen bzw. genauer die technische Plattform dafür, denn um andere Aspekte wie die Kommunikations- und Präsentationssoftware, Organisation, Marketing und ähnliches haben sich dankenswerterweise andere Kollegen gekümmert.

Die zu nutzende Infrastruktur sollte logischerweise die Openstack-Plattform von NWS sein, da hier entsprechende Kapazitäten vorhanden sind, somit hatte ich mein Ziel. Die Ausgangsbasis war auch leicht definiert, da fast alle Schulungen zum Erstellen der virtuellen Maschinen für die praktischen Übungen auf Vagrant setzen. Die somit erstellten Systeme werden dann zwar noch exportiert um die Provisionierung der Schulungsnotebooks zu beschleunigen, aber sollten trotzdem einen guten Start darstellen.

Als erstes musste natürlich dann der Provider installiert werden, da ich Fedora als Betriebssystem nutze, ging das mit dnf install vagrant-openstack-provider. Für die anderen Linux-Systeme habe ich keine Pakete gefunden, daher wird der Rest wohl auf den Plugin-Mechanismus mit vagrant plugin install vagrant-openstack-provider zurückgreifen müssen. Wichtig ist dann noch zu wissen, ob es der einzige oder Standard-Provider ist, denn sonst darf man später beim Starten der Systeme mit vagrant up nicht den entsprechender Parameter --provider=openstack vergessen.

Natürlich stand als erstes aber eine Schulung auf dem Plan, die normalerweise ohne virtuelle Maschine auskommt, was aber nicht so schlimm war, denn es gab mir mehr Freiheit zum Experimentieren und Kennenlernen der Unterschiede zwischen Openstack-Provider und den von mir gewohnten. Der vielleicht größte Unterschied ist, dass hier nicht mit bestehenden Boxen von einem zentralen System wie app.vagrantup.com gearbeitet wird, sondern mit bereits in Openstack vorhandenen Images. Außerdem muss eine Anmeldung an einem Openstack-Projekt erfolgen, in dem dann nicht nur die Images vorbereitet sein müssen, sondern auch die Netzwerkkonfiguration inklusive der Sicherheitsgruppen mit entsprechender Portfreigabe und ein zu verwendender SSH-Key.
read more…

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

NETWAYS Web Services auf der TECHWEEK

Der deutsche Cloud-Markt wächst stetig und die digitale Industrie in Deutschland boomt. Die Veranstaltungsreihe Techweek ist das Event zur digitalen Transformation. Natürlich dürfen wir mit den NETWAYS Web Services bei der Techweek in Frankfurt nicht fehlen! Wir freuen uns darauf, mit den wichtigsten Entscheidungsträgern der deutschen Unternehmenslandschaft ins Gespräch zu kommen und sie von unserer NETWAYS Cloud zu überzeugen!

Ihr seid auch auf der Techweek in Frankfurt? Kommt vorbei, holt euch die neueste NETWAYS Cloud Broschüre und sprecht mit uns! Ihr findet uns an Stand 975.

techweekfrankfurt.de / nws.netways.de/cloud

GitLab CI Runners with Auto-scaling on OpenStack

 

With migrating our CI/CD pipelines from Jenkins to GitLab CI in the past months, we’ve also looked into possible performance enhancements for binary package builds. GitLab and its CI functionality is really really great in this regard, and many things hide under the hood. Did you know that “Auto DevOps” is just an example template for your CI/CD pipeline running in the cloud or your own Kubernetes cluster? But there’s more, the GitLab CI runners can run jobs in different environments with using different hypervisors and the power of docker-machine.

One of them is OpenStack available at NWS and ready to use. The following examples are from the Icinga production environment and help us on a daily basis to build, test and release Icinga products.

 

Preparations

Install the GitLab Runner on the GitLab instance or in a dedicated VM. Follow along in the docs where this is explained in detail. Install the docker-machine binary and inspect its option for creating a new machine.

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
apt-get install -y gitlab-runner
  
curl -L `uname -s`-`uname -m` -o /usr/local/bin/docker-machine
chmod +x /usr/local/bin/docker-machine
  
docker-machine create --driver openstack --help

Next, register the GitLab CI initially. Note: This is just to ensure that the runner is up and running in the GitLab admin interface. You’ll need to modify the configuration in a bit.

gitlab-runner register \
  --non-interactive \
  --url https://git.icinga.com/ \
  --tag-list docker \
  --registration-token SUPERSECRETKEKSI \
  --name "docker-machine on OpenStack" \
  --executor docker+machine \
  --docker-image alpine

 

Docker Machine with OpenStack Deployment

Edit “/etc/gitlab-runner/config.toml” and add/modify the “[[runners]]” section entry for OpenStack and Docker Machine. Ensure that the MachineDriver, MachineName and MachineOptions match the requirements. Within “MachineOptions”, add the credentials, flavors, network settings just as with other deployment providers. All available options are explained in the documentation.

vim /etc/gitlab-runner/config.toml

  [runners.machine]
    IdleCount = 4
    IdleTime = 3600
    MaxBuilds = 100
    MachineDriver = "openstack"
    MachineName = "customer-%s"
    MachineOptions = [
      "openstack-auth-url=https://cloud.netways.de:5000/v3/",
      "openstack-tenant-name=1234-openstack-customer",
      "openstack-username=customer-login",
      "openstack-password=sup3rS3cr3t4ndsup3rl0ng",
      "openstack-flavor-name=s1.large",
      "openstack-image-name=Debian 10.1",
      "openstack-domain-name=default",
      "openstack-net-name=customer-network",
      "openstack-sec-groups="mine",
      "openstack-ssh-user=debian",
      "openstack-user-data-file=/etc/gitlab-runner/user-data",
      "openstack-private-key-file=/etc/gitlab-runner/id_rsa",
      "openstack-keypair-name=GitLab Runner"
    ]

The runners cache can be put onto S3 granted that you have this service available. NWS luckily provides S3 compatible object storage.

  [runners.cache]
    Type = "s3"
    Shared = true
    [runners.cache.s3]
      ServerAddress = "s3provider.domain.localdomain"
      AccessKey = "supersecretaccesskey"
      SecretKey = "supersecretsecretkey"
      BucketName = "openstack-gitlab-runner"

Bootstrap Docker in the OpenStack VM

Last but not least, these VMs need to be bootstrapped with Docker inside a small script. Check the “–engine-install-url” parameter in the help output:

root@icinga-gitlab:/etc/gitlab-runner# docker-machine create --help
  ...
  --engine-install-url "https://get.docker.com"							Custom URL to use for engine installation 

You can use the official way of doing this, but putting this into a small script also allows customizations like QEMU used for Raspbian builds. Ensure that the script is available via HTTP e.g. from a dedicated GitLab repository 😉

#!/bin/sh
#
# This script helps us to prepare a Docker host for the build system
#
# It is used with Docker Machine to install Docker, plus addons
#
# See --engine-install-url at docker-machine create --help

set -e

run() {
  (set -x; "$@")
}

echo "Installing Docker via get.docker.com"
run curl -LsS https://get.docker.com -o /tmp/get-docker.sh
run sh /tmp/get-docker.sh

echo "Installing QEMU and helpers"
run sudo apt-get update
run sudo apt-get install -y qemu-user-static binfmt-support

Once everything is up and running, the GitLab runners are ready to fire the jobs.

 

Auto-Scaling

Jobs and builds are not run all the time, and especially with cloud resources, this should be a cost-efficient thing. When building Icinga 2 for example, the 20+ different distribution jobs generate a usage peak. With the same resources assigned all the time, this would tremendously slow down the build and release times. In that case, it is desirable to automatically spin up more VMs with Docker and let the GitLab runner take care of distributing the jobs. On the other hand, auto-scaling should also shut down resources in idle times.

By default, one has 4 VMs assigned to the GitLab runner. These builds run non-privileged in Docker, the example below also shows another runner which can run privileged builds. This is needed for Docker-in-Docker to create Docker images and push them to GitLab’s container registry.

root@icinga-gitlab:~# docker-machine ls
NAME                                               ACTIVE   DRIVER      STATE     URL                      SWARM   DOCKER     ERRORS
runner-privileged-icinga-1571900582-bed0b282       -        openstack   Running   tcp://10.10.27.10:2376           v19.03.4
runner-privileged-icinga-1571903235-379e0601       -        openstack   Running   tcp://10.10.27.11:2376           v19.03.4
runner-non-privileged-icinga-1571904408-5bb761b5   -        openstack   Running   tcp://10.10.27.20:2376           v19.03.4
runner-non-privileged-icinga-1571904408-52b9bcc4   -        openstack   Running   tcp://10.10.27.21:2376           v19.03.4
runner-non-privileged-icinga-1571904408-97bf8992   -        openstack   Running   tcp://10.10.27.22:2376           v19.03.4
runner-non-privileged-icinga-1571904408-97bf8992   -        openstack   Running   tcp://10.10.27.22:2376           v19.03.4

Once it detects a peak in the pending job pipeline, the runner is allowed to start additional VMs in OpenStack.

root@icinga-gitlab:~# docker-machine ls
NAME                                               ACTIVE   DRIVER      STATE     URL                      SWARM   DOCKER     ERRORS
runner-privileged-icinga-1571900582-bed0b282       -        openstack   Running   tcp://10.10.27.10:2376           v19.03.4
runner-privileged-icinga-1571903235-379e0601       -        openstack   Running   tcp://10.10.27.11:2376           v19.03.4
runner-non-privileged-icinga-1571904408-5bb761b5   -        openstack   Running   tcp://10.10.27.20:2376           v19.03.4
runner-non-privileged-icinga-1571904408-52b9bcc4   -        openstack   Running   tcp://10.10.27.21:2376           v19.03.4
runner-non-privileged-icinga-1571904408-97bf8992   -        openstack   Running   tcp://10.10.27.22:2376           v19.03.4
runner-non-privileged-icinga-1571904408-97bf8992   -        openstack   Running   tcp://10.10.27.23:2376           v19.03.4

...

runner-non-privileged-icinga-1571904534-0661c396   -        openstack   Running   tcp://10.10.27.24:2376           v19.03.4
runner-non-privileged-icinga-1571904543-6e9622fd   -        openstack   Running   tcp://10.10.27.25:2376           v19.03.4
runner-non-privileged-icinga-1571904549-c456e119   -        openstack   Running   tcp://10.10.27.27:2376           v19.03.4
runner-non-privileged-icinga-1571904750-8f6b08c8   -        openstack   Running   tcp://10.10.27.29:2376           v19.03.4

 

In order to achieve this setting, modify the runner configuration and increase the limit.

vim /etc/gitlab-runner/config.toml

[[runners]]
  name = "docker-machine on OpenStack"
  limit = 24
  output_limit = 20480
  url = "https://git.icinga.com/"
  token = "supersecrettoken"
  executor = "docker+machine"

This would result in 24 OpenStack VMs after a while, and all are idle 24/7. In order to automatically decrease the deployed VMs, use the OffPeak settings. This also ensures that resources are available during workhours while spare time and weekend are considered “off peak” with shutting down unneeded resources automatically.

    OffPeakTimezone = "Europe/Berlin"
    OffPeakIdleCount = 2
    OffPeakIdleTime = 1800
    OffPeakPeriods = [
      "* * 0-8,22-23 * * mon-fri *",
      "* * * * * sat,sun *"
    ]

Pretty neat functionality 🙂

 

Troubleshooting & Monitoring

“docker-machine ls” provides the full overview and tells whenever e.g. a connection to OpenStack did not work, or if the VM is currently unavailable.

root@icinga-gitlab:~# docker-machine ls
NAME                                               ACTIVE   DRIVER      STATE     URL                      SWARM   DOCKER     ERRORS
runner-privileged-icinga-1571900582-bed0b282       -        openstack   Error                                      Unknown    Expected HTTP response code [200 203] when accessing [GET https://cloud.netways.de:8774/v2.1/servers/], but got 404 instead

In case you have deleted the running VMs to start fresh, provisioning might take a while and the above can be a false positive. Check the OpenStack management interface to see whether the VMs booted correctly. You can also remove a VM with “docker-machine rm <id>” and run “gitlab-runner restart” to automatically provision it again.

Whenever the VM provisioning fails, a gentle look into the syslog (or runner log) unveils what’s the problem. Lately we had used a wrong OpenStack flavor configuration which was fixed after investigating in the logs.

Oct 18 07:08:48 3 icinga-gitlab gitlab-runner[30988]:  #033[31;1mERROR: Error creating machine: Error in driver during machine creation: Unable to find flavor named 1234-customer-id-4-8#033[0;m  #033[31;1mdriver#033[0;m=openstack #033[31;1mname#033[0;m=runner-non-privilegued-icinga-1571375325-3f8176c3 #033[31;1moperation#033[0;m=create

Monitoring your GitLab CI runners is key, and with the help of the REST API, this becomes a breeze with Icinga checks. You can inspect the runner state and notify everyone on-call whenever CI pipelines are stuck.

 

Conclusion

Developers depend on fast CI feedback these days, speeding up their workflow – make them move fast again. Admins need to understand their requirements, and everyone needs a deep-dive into GitLab and its possibilities. Join our training sessions for more practical exercises or immediately start playing in NWS!