NWS Cloud and Terraform – does this work?

NWS Cloud and Terraform – does this work?

A few months ago we launched our OpenStack project within our NWS platform. The NWS Cloud was born.
Since then we are trying to increase the performance and the possibilities of the cloud. And nowadays there is no way around Terraform.

So i had a look at the possibilities and had to try them out. One of my first runs should create a virtual machine, create some security rules, attach a public IP to the virtual machine and install a webserver with a customized index.html

And how this works, i want to show now.

 

But first of all, i have to save my credentials in my config file

variables.tf

variable "openstack_user_name" { description = "The username for the Tenant." default = "my-nws-user" } variable "openstack_tenant_name" { description = "The name of the Tenant." default = "my-nws-project" } variable "openstack_password" { description = "The password for the Tenant." default = "my-password" } variable "openstack_auth_url" { description = "The endpoint url to connect to OpenStack." default = "nws-cloud" } variable "openstack_keypair" { description = "The keypair to be used." default = "mgebert" } variable "tenant_network" { description = "The network to be used." default = "my-nws-project" }

With this variables i can now start writing the rest of my files. I had to configure the provider

provider.tf

provider "openstack" { user_name = "${var.openstack_user_name}" tenant_name = "${var.openstack_tenant_name}" password = "${var.openstack_password}" auth_url = "${var.openstack_auth_url}" }

And the “script” which should run on the new virtual machine

bootstrapweb.sh

#!/bin/bash apt update apt install -y apache2 cat <<EOF > /var/www/html/index.html <html> <body> <p>hostname is: $(hostname)</p> </body> </html> EOF chown -R www-data:www-data /var/www/html systemctl apache2 start

But there is still no server right? So i have to write my deploy file.

deploy.tf

resource "openstack_networking_secgroup_v2" "secgroup1" { name = "ALLOW SSH AND HTTP" } resource "openstack_networking_secgroup_rule_v2" "secgroup_rule_1" { direction = "ingress" ethertype = "IPv4" protocol = "tcp" port_range_min = 22 port_range_max = 22 remote_ip_prefix = "0.0.0.0/0" security_group_id = "${openstack_networking_secgroup_v2.secgroup1.id}" } resource "openstack_networking_secgroup_rule_v2" "secgroup_rule_2" { direction = "ingress" ethertype = "IPv4" protocol = "tcp" port_range_min = 80 port_range_max = 80 remote_ip_prefix = "0.0.0.0/0" security_group_id = "${openstack_networking_secgroup_v2.secgroup1.id}" } resource "openstack_networking_secgroup_rule_v2" "secgroup_rule_3" { direction = "ingress" ethertype = "IPv4" protocol = "icmp" remote_ip_prefix = "0.0.0.0/0" security_group_id = "${openstack_networking_secgroup_v2.secgroup1.id}" } resource "openstack_compute_instance_v2" "web" { name = "web01" image_name = "Ubuntu Xenial" availability_zone = "HetznerNBG4" flavor_name = "s2.small" key_pair = "${var.openstack_keypair}" security_groups = ["default","ALLOW SSH AND HTTP"] network { name = "${var.tenant_network}" } user_data = "${file("bootstrapweb.sh")}" } resource "openstack_networking_floatingip_v2" "floating" { pool = "public-network" } resource "openstack_compute_floatingip_associate_v2" "floating" { floating_ip = "${openstack_networking_floatingip_v2.floating.address}" instance_id = "${openstack_compute_instance_v2.web.id}" }

 

In this file i configure first of all the new security group and afterwards 3 rules to allow ICMP, HTTP and SSH. Then we can start the virtual machine with a name, image_name, a flavor_name, security_groups and so on. I could configure more, like a loop which creates me 10 web-servers with the name web-01 to web-10 . But for now, thats fine. When the server is up and running, the deploy will attach a floating IP to it, so i can access it without a VPN.

And thats it, basically. When it is installed, the bootstrapweb.sh will install the apache2 webserver and replace the default index.html with my custom one.

There is almost no setup which can’t be build up with terraform in combination with the NWS Cloud – so just try it yourself

If you want to see the code above in action, have a look at this video!

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

Terraform Changes

Hallo!

Was vielen von unseren Lesern entgeht, ist das wir auch in unserem Alltag zwischen der ganzen Softwareschreiber- und Kompilier- Tätigkeiten auch ganz viele virtuelle Maschinen und Container zum testen selbiger Software rauf und runter installieren müssen, und das Tag für Tag.

Deshalb versuchen wir uns das Leben mit dafür erstellter Software und deren arbeitserleichternden Funktionen leichter zu machen. Wie mein Kollege schon in seinem Blogpost im März mir vorgegriffen hat, benutzen wir bei der Netways Terraform. Achim wird in weiteren Artikeln darauf eingehen wie man Openstack per Terraform nach seiner Pfeife tanzen lassen kann und Ich möchte mich heute auf ein anderes Terraform Thema beziehen, nämlich dem nahen Release von Terraform 0.12.

Zu dem Zeitpunkt wo ich diese Zeilen niederschreibe, ist auf der aktuellen Website von Hashicorp noch die Aktuelle Version 0.11.13 zu finden.

Aber Terraform hat uns schon vielversprechendes gezeigt mit dem 0.12.0-beta1 pre-release.

Damit kann man schon die vielen Erleichterungen, welche der neue Terraform Release mit sich bringt erahnen und auch schon antesten. Ich versuche die Änderungen Anhand eines kleinen Beispiels zu erläutern.
Vielleicht kann ich den einen oder anderen IaaS Codeschreiber, welcher sich hierfür interessiert, etwas auf den Geschmack zu bringen schon etwas zu testen mit der neuen Version.

Hier der Unterschied zwischen einer (aktuell 0.11.13) alten Terraform Version und einer neuen Version in Terraform 0.12 durch eine Gegenüberstellung.

main.tf (Random Tiernamen Beispiel)

variable "count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "zoo_enabled" { default = "0" } variable "prefix_liste" { default = [] } resource "random_pet" "my_pet" { count = "${var.count}" prefix = "${var.zoo_enabled == "0" ? var.default_prefix : element(concat(var.prefix_liste, list (""), count.index)}" }

main.tf HCL2 Version(Random Tiernamen Beispiel)

variable "pet_count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "prefix_list" { default = [] } resource "random_pet" "my_pet" { count = var.pet_count prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix }

Die Unterschiede fallen zuerst etwas weniger ins Auge, sind aber dafür meines Erachtens tiefgreifender für Leute, die IaaS Code schreiben müssen und dienen der Lesbarkeit des Codes.

Vorteil Nummer 1:
Im alten Beispiel musste noch mit “${var.count}” von einem String zu einer Number evaluiert werden. Mit der neuen HCL2 Schreibweise entfällt das, und es kann mit var.pet_count direkt der korrekte String oder Number Wert adressiert werden.

Vorteil Nummer 2:
Auch die Evaluierung der Liste prefix = “${var.zoo_enabled == “0” ? var.default_prefix : element(concat(var.prefix_liste, list (“”), count.index)}”  wird mit der neuen Notation der HCL2 wesentlich eingängiger. prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix ist prägnanter. Es entfällt auch die element(concat(x), list(“”), x ) Hack-Situation, um aus einer leeren Liste auch eine Liste mit einem NULL Element zum machen.

Weitere Vorteile: es gibt viel mehr was geändert worden ist, if you want to know more, klick here.

Ich hoffe ich habe euch nicht zu sehr gelangweilt mit C.O.D.E. kurz vor dem Wochenende.

Gruß David

 

David Okon
David Okon
Support Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...
Quick and Dirty: OpenStack + CoreOS + GitLab Runner

Quick and Dirty: OpenStack + CoreOS + GitLab Runner

Wer in GitLab die CI/CD-Features nutzen möchte und nicht zufällig einen ungenutzten Kubernetes-Cluster übrig hat, mit dem man GitLab’s Auto DevOps Funktion einrichten kann, der benötigt zumindest einen GitLab Runner, um Build-Jobs und Tests zum Laufen zu bekommen.
Der GitLab Runner ist eine zusätzliche Anwendung, welche sich ausschließlich darum kümmert, bei einer GitLab-CE/-EE Instanz die CI/CD-Aufträge abzuholen und diese abzuarbeiten. Der Runner muss dabei nicht zwingend auf dem selben System wie das GitLab installiert sein und kann somit auch extern auf einem anderen Host laufen. Der Hintergrund, weshalb man das auch so umsetzen sollte, ist eigentlich recht klar: ein GitLab Runner steht bei einer aktiven CI/CD-Pipeline oftmals unter hoher Last und würde er auf dem gleichen Host wie das GitLab selbst laufen, so könnte er dessen Performance stark beeinträchtigen. Deshalb macht es Sinn, den GitLab Runner z.B. auf eine VM in OpenStack auszulagern.
In diesem Blogpost werde ich kurz darauf eingehen, wie man schnell und einfach eine GitLab Runner VM per CLI in OpenStack aufsetzen kann. Da ich den Runner als Docker-Container starten möchte, bietet sich CoreOS an. CoreOS kommt mit Docker vorinstalliert und es bietet die Möglichkeit per Ignition Config nach dem Start des Betriebssystems Container, oder auch andere Prozesse, automatisch starten zu lassen.

Sobald man sich bei seinem OpenStack-Anbieter in sein Projekt eingeloggt hat, kann man sich dort unter “API Zugriff” die OpenStack-RC-Datei herunterladen. Damit kann man sich dann recht einfach per CLI bei OpenStack authentifizieren. Voraussetzung für die Nutzung der CLI ist, dass man bei sich den OpenStack Command-Line Client installiert hat.
Sobald man beides hat, kann es auch schon losgehen:

    1. Runner Registration Token abholen
      Dazu loggt man sich als Admin in sein GitLab-CE/-EE ein und navigiert zu “Admin Area” -> “Overview” -> “Runners”. Hier findet man den aktuellen Registration Token.
    2. CoreOS Ignition Config
      Die Konfigurationsdatei für CoreOS nennt man z.B. config.ign. Diese legt man sich ebenfalls auf dem Rechner ab.
      Der Inhalt muss im nächsten Schritt geringfügig angepasst werden.

      config.ign

      { "ignition": { "version": "2.2.0", "config": {} }, "storage": { "filesystems": [{ "mount": { "device": "/dev/disk/by-label/ROOT", "format": "btrfs", "wipeFilesystem": true, "label": "ROOT" } }] }, "storage": { "files": [{ "filesystem": "root", "path": "/etc/hostname", "mode": 420, "contents": { "source": "data:,core1" } }, { "filesystem": "root", "path": "/home/core/config.toml", "mode": 644, "contents": { "source": "data:,concurrent=4" } } ] }, "systemd": { "units": [ { "name": "gitlab-runner.service", "enable": true, "contents": "[Service]\nType=simple\nRestart=always\nRestartSec=10\nExecStartPre=/sbin/rngd -r /dev/urandom\nExecStart=/usr/bin/docker run --rm --name gitlab-runner -e 'GIT_SSL_NO_VERIFY=true' -v /home/core:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:v11.8.0 \n\n[Install]\nWantedBy=multi-user.target" }, { "name": "gitlab-runner-register.service", "enable": true, "contents": "[Unit]\nRequires=gitlab-runner.service\n[Service]\nType=simple\nRestart=on-failure\nRestartSec=20\nExecStart=/usr/bin/docker exec gitlab-runner gitlab-runner register -n --env 'GIT_SSL_NO_VERIFY=true' --url https://$URL -r $TOKEN --description myOpenStackRunner--locked=false --executor docker --docker-volumes /var/run/docker.sock:/var/run/docker.sock --docker-image ruby:2.5 \n\n[Install]\nWantedBy=multi-user.target" } ] }, "networkd": {}, "passwd": { "users": [ { "name": "core", "sshAuthorizedKeys": [ "$your-ssh-pub-key" ] } ] } }
    3. Ignition Config anpassen
      Beim Systemd-Unit “gitlab-runner-register.service” setzt man im Content bei den Variablen “$URL” den FQDN der eigenen GitLab-Instanz und bei “$TOKEN” den in Schritt 1 kopierten Registration Token ein.
      Außerdem kann man gleich noch seinen SSH-Key mitgeben, damit man später auch per SSH auf die VM zugreifen kann. Diesen hinterlegt man unter dem Abschnitt “passwd” im Platzhalter “$your-ssh-pub-key”.
    4. CLI Commands
      Nun kann man sich auch schon das Kommando zum anlegen der VM zusammenbauen.
      Als erstes muss man sich bei OpenStack authentifizieren, indem man die Datei sourced, die man sich eingangs aus seinem OpenStack Projekt geladen hat und dabei sein OpenStack Passwort angibt:

      source projectname-openrc.sh

      Man sollte außerdem sicherstellen, dass in dem Projekt ein CoreOS Image zur Verfügung steht.
      Anschließend kann man nach folgendem Schema die Runner-VM anlegen:

      openstack server create --network 1826-openstack-7f8d2 --user-data config.ign --flavor s1.medium --image CoreOS_Live "GitLab Runner"

      Network, Flavor und Image sollten aber individuell noch angepasst werden.

    Nach ca. zwei Minuten sollte dann der Runner auch schon zur Verfügung stehen. Überprüfen lässt sich das, indem man sich als Admin in seine GitLab-Instanz einloggt und im Bereich unter “Admin Area” -> “Overview” -> “Runners” nach einem Runner mit dem Namen “myOpenStackRunner” nachsieht.

    Wer noch auf der Suche nach einem OpenStack-Provider ist, der wird bei den NETWAYS Web Services fündig. Mit nur wenigen Clicks hat man sein eigenes OpenStack-Projekt und kann sofort loslegen.

Gabriel Hartmann
Gabriel Hartmann
Systems Engineer

Gabriel hat 2016 als Auszubildender Fachinformatiker für Systemintegrator bei NETWAYS angefangen und 2019 die Ausbildung abgeschlossen. Als Mitglied des Web Services Teams kümmert er sich seither um viele technische Themen, die mit den NETWAYS Web Services und der Weiterentwicklung der Plattform zu tun haben. Aber auch im Support engagiert er sich, um den Kunden von NWS bei Fragen und Problemen zur Seite zu stehen.

Infrastructure as Code mit Terraform und Openstack

This entry is part 1 of 1 in the series Openstack und Terraform Beispiele

Der Drang weg von Hardware zu einer virtuellen oder sogar serverless Infrastruktur ist weiterhin stark. Nicht alle Administratoren oder Entwickler denken sofort an eine Containerplattform wie Kubernetes oder serverless functions sondern verlagern die eigene Infrastruktur in eine Public Cloud. Dadurch bleiben einem lästige Aufgaben in Kalt- und Warmgängen im Rechenzentrum erspart und es bleibt mehr Zeit für anderen Tätigkeiten. Cloud Plattformen wie OpenStack bieten alle nötigen virtuelle Ressourcen die auch in einem Rechenzentrum vorhanden sind, nur dass diese in wenigen Sekunden verfügbar sind. So kann man Komponente wie z.B. Router, Bridges, Interfaces, Server (VMs), Storage (von Block bis Object) und andere schnell und einfach über offene Schnittstellen erstellen und verwalten.

Dies gibt uns Administratoren auch die Möglichkeit unsere Infrastruktur in Textdateien zu beschreiben, zu automatisieren und zu verwalten. Unter dem Buzzword Infrastructure as Code findet man viele Tools die einem hier unterstützen und Terraform ist eines der bekanntesten um z.B. Ressourcen in OpenStack zu verwalten. Mit meinen nächsten Blogposts will ich mit vielen Beispielen zeigen wie man mit Terraform seine virtuelle Ressourcen in der Netways Cloud verwalten kann. Mehr zum Thema Terraform gibt es auch im Talk von Anton Babenko auf der OSDC.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Edge-Cloud-Computing – Cloud to the Edge

Während man in Deutschland immer noch und immer wieder in Funklöchern sitzt und oftmals nur 2G als Datenübertragung nutzen kann, bereitet sich die Welt – auch Deutschland – auf den nächsten Standard vor: 5G. Die neue Generation besticht durch hohe Bandbreiten (~1-20Gbps), niedrige Latenzen und eine hohe mögliche Dichte von Geräten auf neuen Frequenzbändern, die natürlich heiß begehrt sind. Braucht man aber solch hohe Bandbreiten und niedrige Latenzen um seine E-Mails zu checken oder Social Media Inhalte zu betrachten? Wohl eher nicht. Diese neuen Anforderungen an das Netzwerk benötigen aber Anwendungen, die in Zukunft vermutlich nicht mehr wegzudenken sind und maßgeblich unsere Welt verändern könnten – so zumindest die Vision. Autonomes Fahren, künstliche Intelligenz, Augmented- und Virtual-Reality und Internet of Things sind nur einige Anwendungsbereiche, die durch den neuen Standard ihre Möglichkeiten besser ausschöpfen können.

Ein völlig autonom fahrendes Auto, gespickt mit mehreren hundert Sensoren und vielen Kameras, produziert eine gewaltige Menge an Daten, die in einer Cloud zum Beispiel zur Koordination anderer Fahrzeuge eingespeist und verarbeitet werden. Ein weiteres Beispiel wäre die Videoüberwachung in einer U-Bahn kombiniert mit den Aufzeichnungen der Kameras vom Bahnsteig, die in Echtzeit menschliche Verhaltensmuster analysiert oder gar erlernt und entsprechend entscheidet. Benötigt es eine Vollbremsung, weil ein Passant gerade am Bahnsteig mit böser Absicht geschubst wird oder ist es eher eine harmlose Situation unter Freunden? Damit das funktioniert, benötigt man nicht nur ein schnelles Mobilfunknetz sondern auch Edge-Cloud-Computing.

Edge-Cloud-Computing

Edge-Cloud-Computing ist zu Recht einer der letzten und heißesten Trends im Bereich Cloud-Computing. Dabei gilt es, seine zentrale Cloud an den Rand (Edge) zu bewegen – also näher an den Kunden. Mit anderen Worten eine verteilte Cloud. Was genau jetzt der Rand sein soll ist noch nicht so ganz klar, man nimmt einen Bereich an, der nicht weiter als 20ms vom Endgerät entfernt ist. An diesem Rand ist es also nun notwendig, seine Cloud-Compute-Ressourcen verfügbar zu haben und nutzen zu können, um entsprechende Workload darauf zu betreiben. Ob die Workload in Containern, VMs oder Bare-Metal betrieben wird ist eher nachrangig zu betrachten, der Mix wird es sein. Dabei stützt man sich auf bestehende Technologie-Komponenten wie etwa Ceph, Qemu, Kubernetes, DPDK, OpenVSwitch und so weiter. 5G alleine wird also ohne Edge-Computing vermutlich nicht reichen, um zukünftigen Anwendungen gerecht zu werden.

Die beiden Open-Source Cloud-Lösungen, OpenNebula und OpenStack, die wir auch bei NETWAYS im Einsatz haben, sind natürlich bereits auf den Hype-Train aufgesprungen. OpenNebula hat gleich ihr gestriges Release 5.8 dem Codenamen “Edge” verpasst und OpenStack hat mit StarlingX sein eigenes Projekt und ein “Edge Computing Group” Gremium ins Leben gerufen.

Man kann wirklich gespannt sein was die Zukunft bringen wird und wie die Herausforderungen technisch realisiert werden.

Anwendungen, die ohne 5G und Edge auskommen, können aber auch schon heute in unserer Cloud basierend auf OpenStack modern, zeitgemäß und zukunftssicher betrieben werden.

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sepp 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 zusammen mit Martin das Managed Services Team. Wenn er nicht gerade Server in MCollective einbindet, versucht er mit seinem Motorrad einen neuen Geschwindigkeitsrekord aufzustellen.

Mit MyEngineer voll ins Schwarze getroffen

Fachkräftemangel? Keine Ressourcen für neue Hostingprojekte? Mit MyEngineer von Netways kein Thema mehr!

Nach Einführung unserer IaaS OpenStack buchen immer mehr Kunden zusätzlich unseren MyEngineer-Service. MyEngineer ist praktisch Ihr persönlicher und erfahrener Hosting-Administrator (Systems Engineer), der nie krank wird und ohne Urlaub auskommt, der Ihnen auf Wunsch sogar 24 Stunden an 7 Tagen die Woche zu Verfügung steht.

Gibt es nicht? Doch! Bei Netways Managed Services!

Und Ihr MyEngineer ist auch noch mehr als fair zu Ihnen. Seine Arbeiten werden nur abgerechnet, wenn er für Sie tätig wurde. Also z.B. keine monatlichen Pauschalen mehr, bei denen man oft nicht weiß, was darin verborgen ist. Oder keine festen Ersteinrichtungsgebühren. Es wird nur abgerechnet, was VORHER als Dienstleistung vereinbart wurde und nur nach tatsächlich erbrachtem Aufwand in 15-Minuten-Intervallen.

Welche Kunden buchen ihren MyEngineer?

  • Startups, die sich nicht mit eigener IT belasten wollen
  • Marketing Agenturen, die für neue Kundenprojekte zusätzliche, erfahrene Manpower benötigen
  • Hosting-Kunden, die für ihre Projekte spezielle Expertise benötigen
  • Kunden, die ihre eigene IT reduzieren wollen oder müssen und gleichzeitig auf Grund unserer Erfahrungen ihre IT-Leistungen verbessern wollen
  • Kunden mit „Not am Mann“

Fragen? Bitte fragen!

Überzeugt? Kommen Sie mit Ihrem Projekt zu uns! Alles weitere zu OpenStack finden Sie hier und Ihren MyEngineer hier.

Manfred Schlutz
Manfred Schlutz
Senior Account Manager

Manfred ist seit Oktober 2017 als Senior Account Manager bei NETWAYS tätig. Schon seit 1981 kümmert er sich bei verschiedenen Firmen um vertriebliche Angelegenheiten, zuletzt war er elf Jahre im Hardwaregeschäft als Key Accounter tätig. Besonders gut an seinem Job gefällt ihm, dass er jeden Tag auf’s Neue andere Menschen kennenlernt. In seiner Freizeit genießt es der gebürtige Münsterländer besonders, sich seinem Hobby, dem Modellbau zu widmen. Weitere heiße Diskussionsthemen für eure Unterhaltung mit Manfred...