Cachet now available at NETWAYS Web Services

We think communication is crucial. Especially during downtimes. That’s why we release a new app today. An app, which allows you to share all necessary information about your services and servers with your users. Cachet is software that improves downtime.

Cachet is a status page, which is very simple to use, yet it offers many opportunities, to better communicate downtime and system outages to customers, teams and shareholders. You can display the status of your services, websites and servers. You can create and show metrics, plan maintenances or inform your users about current issues.

 

 

Cachet comes with a powerfull API. In the detailed documentation you can generate your calls for whatever you want to create or change. All information which can be created and edited in the admin panel, can also be created and changed with an API call. The interesting part about Cachet is that administrators have the opportunity to automate the updates. For example with data of your monitoring or some scripts on your hosts which check some services.

In the following command, you would create a new incident with the name “Down” and the message “A server went down“.

  • It will be in the state “1“, which means “investigating
  • The component which is affected by this incident has the id 2, which is in this case “My Login
  • The component will be in state “4“, which means “Major Outage
  • Notify: true – so your user would receive an email with about this incident.

mgebert@MacBook-Pro ~ $ curl --request POST --url https://cachet-demo.nws.netways.de/api/v1/incidents -H "Content-Type: application/json;" -H "X-Cachet-Token: j5t0mNvvh57ubO84TxJq" --data '{"name":"Down","message":"A server went down.","status":1,"visible":1,"component_id":2,"component_status":4,"notify":"true"}'

If you want to notify your users as soon as an incident was reported, you will have to configure the credentials for your mailserver and enable the “Subscribe” button, which can be done in the settings quite simple.

But if you don’t want to use the API, you can create and manage your information just by changing the states of your components and incidents, as you can see in the screenshots below.

 

You can start your own Cachet app at the NWS platform now on our platform. First 30 days are for free and the app will be ready within 5 minutes – so what are you waiting for?

Last but not least, I want to share with you the link to a temporary available demo installation, so you can have a look at it right now. Check it out!

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...

Trefft unser NETWAYS Web Services Team auf der DOST!

Die DOST hat sich nachhaltig als anerkannte Fachkonferenz rund um den Betrieb modularer Cloud-Plattformen etabliert. Da dürfen unsere Kollegen von NETWAYS Web Services natürlich nicht fehlen! Wir werden als Konferenzteilnehmer vor Ort vertreten sein, aber auch als Sponsor mit einem Stand in der Sponsorenausstellung. Egal ob nach oder vor einem Vortrag oder an unserem Stand – sprecht uns an!

Wir freuen uns auf interessante Gespräche zu Cloud und Co.!

Erzählt uns von euren Systemen und Lösungen und erfahrt von uns alles, was es zur NETWAYS Cloud auf OpenStack-Basis zu wissen gibt!

Das Programm, Tickets und alles weitere zur DOST: https://openstack-tage.de/

Alles zur NETWAYS Cloud: https://nws.netways.de/de/cloud/

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

Eine Reise in Richtung Graylog – Webinar Serie

Nachdem die Sommerpause mit unseren Webinaren wieder vorbei ist, wollen wir gleich richtig durchstarten! Diesmal befassen wir uns mit einer Webinar-Serie rund um die Lösung Graylog, welche wir gemeinsam mit den Kollegen von Graylog durchführen.
Ziel ist es, vor allem die Möglichkeiten und die einfache Installation/Konfiguration aufzuzeigen und einen gesamten Überblick zu gewährleisten.

Starten werden wir daher direkt am 04. September um 10:30 Uhr mit dem ersten Teil “Graylog: Aufbau einer Log-Managament Umgebung“. Eine Anmeldung ist hier möglich.

Selbstverständlich haben wir die nächsten Teile bereits eingeplant – eine Übersicht findet sich in unserem Webinar-Kalender, oder ihr lest einfach weiter:

Wer darüber hinaus noch an unseren OpenStack Webinaren oder an unserer Cloud interessiert ist, der wird in diesem Jahr ebenfalls noch etwas geboten bekommen:

Wie üblich werden alle Webinare aufgezeichnet und auf unserem YouTube Channel veröffentlicht. Wir freuen uns auf eure Teilnahme und sind natürlich auch für Themen-Vorschläge offen!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Migration von GitLab mit Upgrade auf EE

Wer GitLab CE produktiv im Einsatz hat und mit den zusätzlichen Features der EE Version liebäugelt, der wird sich beim Umstieg zwangsläufig mit den Migrationsschritten auseinandersetzen, sofern der GitLab Server nicht von einem Hoster betreut wird. In diesem Post zeige ich, wie der Wechsel inklusive Migration auf einen anderen Server gelingen kann und beziehe mich dabei auf die Omnibus Version basierend auf Ubuntu 18.04. Der Ablauf ist gar nicht so kompliziert. Bügelt man die EE-Version einfach über die aktuelle CE Version, dann hat man nur zwei Schritte zu beachten. Wenn man allerdings einen EE Server parallel hochzieht, um dann auf diesen zu migrieren, so kommen ein paar mehr Schritte hinzu.
Deshalb zeige ich im Folgenden wie man per Backup und Restore auch zum Ziel kommt. Die ersten Schritte sind ziemlich identisch mit dem, was GitLab vorgibt.

  1. Zuerst erstellt man sich ein Backup:
    gitlab-rake gitlab:backup:create STRATEGY=copy

    Einfach um sich den aktuellen Stand vor der Migration zu sichern.
    Hier kann nicht viel schief gehen. Man sollte aber darauf achten, dass genügend Speicherplatz unter /var/opt/gitlab/backups zur Verfügung steht. Es sollten mindestens noch zwei Drittel des Speicherplatzes frei sein. Das resultierende Tar-Archiv sollte man sich anschließend weg kopieren, da im weiteren Verlauf ein weitere Backup erstellt wird.

  2.  Nun führt man das Script von GitLab aus, das die apt-Sourcen hinzufügt und ein paar benötigte Pakete vorinstalliert:
    curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
  3. Jetzt checkt man noch kurz welche Versionsnummer von GitLab CE momentan installiert ist:
    dpkg -l |grep gitlab-ce
  4. Danach installiert man die GitLab EE Version. Dabei wird die CE Version gelöscht und eine Migration durchgeführt. Um den Versionsstand kompatibel zu halten, verwendet man die gleiche Versionsnummer wie aus dem vorherigen Schritt. Lediglich der teil ‘ce’ wird zu ‘ee’ abgeändert:
    apt-get update && sudo apt-get install gitlab-ee=12.1.6-ee.0
  5. Nun erstellt man erneut ein Backup:
    gitlab-rake gitlab:backup:create STRATEGY=copy
  6. Das neu erstellte Backup transferiert man einschließlich der Dateien /etc/gitlab/gitlab-secrets.json und /etc/gitlab/gitlab.rb auf den EE Server. Das lässt sich z.B. per scp bewerkstelligen:
    scp /var/opt/gitlab/backups/*ee_gitlab_backup.tar ziel-server:./
    scp /etc/gitlab/gitlab-secrets.json ziel-server:./
    scp /etc/gitlab/gitlab.rb ziel-server:./
  7. Auf dem Zielserver sollte man natürlich GitLab EE in der entsprechenden Version installieren. Hier hält man sich am besten an die offizielle Anleitung. Nicht vergessen bei der Installation die Versionsnummer anzugeben.
  8. Jetzt verschiebt man die Dateien die man per scp transferiert hat und setzt die Dateiberechtigungen:
    mv ~/*ee_gitlab_backup.tar /var/opt/gitlab/backups
    mv ~/gitlab-secrets.json ~/gitlab.rb /etc/gitlab/
    chown root:root /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb
    chown git:git /var/opt/gitlab/backups/*ee_gitlab_backup.tar
  9. Dann startet man den Restore:
    gitlab-rake gitlab:backup:restore

    Man quittiert die einzelnen Abfragen mit ‘yes’. Hat sich die URL für den neuen EE Server geändert, dann sollte man das in der /etc/gitlab.rb anpassen. In diesem Fall sind auch Änderungen an den GitLab Runnern vorzunehmen. Es reicht dann allerdings wenn man auf dem jeweiligen Runner in der Datei config.toml die URL in der [[runners]] Sektion anpasst, da der Token gleich bleibt.

Troubleshooting:

Es ist allerdings auch möglich, dass es zu Problemen mit den Runnern kommt. Dies zeigt sich z.B. dadurch, dass der Runner in seinen Logs 500er-Fehler beim Verbindungsversuch zum GitLab meldet. In diesem Fall sollte man zuerst versuchen den Runner neu zu registrieren. Falls die Fehler bestehen bleiben, ist es möglich, dass diese durch einen CI-Job verursacht werden, der während der Migration noch lief. So war es zumindest bei mir der Fall. Mit Hilfe der Anleitung zum Troubleshooting und den Infos aus diesem Issue kam ich dann zum Ziel:

gitlab-rails dbconsole
UPDATE ci_builds SET token_encrypted = NULL WHERE status in ('created', 'pending');

Wenn man sich das alles sparen möchte, dann lohnt es sich einen Blick auf unsere GitLab Angebote der NETWAYS Web Services zu werfen.

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.
NWS – because web services don’t have to be complicated

NWS – because web services don’t have to be complicated

Web services platforms are a common way nowadays, to run your services without the need of your own infrastructure. No matter if you need a safe place for your data, an app to communicate with people or just a place to run your own services. But what do you know about the platform of your choice?

  • Do you know how your data is stored?
  • Do you know where the servers are located in detail?
  • Do you know the people which are giving you support?
  • Do you know what happens in case of a critical issue?

I bet, most of you, or at least some of you, don’t. But that’s the point where we start. We want to be different. We want to be transparent and uncomplicated.

Our servers are located in Nuremberg – Germany. We are running them in two different datacenters to ensure high security.

Working with our apps is pretty simple. Just start them! There is no complicated registration process, just fill in the form and you are good to go. The best thing is: you don’t even need a domain or some know how of SSL. It’s already configured for you! Of course you can use your own domain and certificates if you want, but you don’t have to.
If you are curious about how our apps are working in detail or what features are available in our apps, just have a look at our FAQs
Still can’t find what you are looking for? Contact us via live chat! If there is no live chat agent available, an automated ticket will be created, so we can get in touch with you.

But whats so special about our support? Well, it’s quick, it’s professional, it’s individual and most important of all: Our developers and administrators are your support team.

We also want to create our bills as transparent as possible. In case of our OpenStack cloud, you won’t just get a bill with an amount. You will get a detailed report of all resources you used in the past month. Which IP was used how long? How many CPUs were used how long and which VM did use them? But thats still not all. We want to give you the possibility to check at a various day of the month, how much money you spent on our cloud so far and how much you will spent till the end of the month.

Keep track of whats going on! And even if you have your applications running on a different platform – we will help you migrating your data with almost no downtime. Because we take care.

Most features we released for our apps and the platform itself, were not features “we wanted” to release. Don’t get me wrong here, we also wanted to release them, but most of them were features our customers requested and needed.

And we got one more thing. If you don’t know if you can trust us, you can just give it a try. Ask us anything or just try our services – 30 days for free (OpenStack is excluded here – but just get in touch with us. We will find a solution that fit your needs.).

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...