AnsibleFest London

Thilo, mein alter Azubi Kollege, und ich haben dieses Jahr das erste mal am AnsibleFest in London teilgenommen. Ziel davon war es, den Blickwinkel zu erweitern und zu sehen, welche Möglichkeiten es mit Ansible gibt und wie sie von anderen Unternehmen ausgeschöpft werden.
Die Unternehmen, die Vorträge gehalte oder an Interviews teilgenommen haben, erstrecken sich von Siemens, über Ansible selbst bis hin zur britischen Armee. Mich hat sehr erstaunt, dass sogar die britische Armee Ansible im produktiven Einsatz hat und dann auch einen Talk darüber abhält!

Das Ambiente war sehr vornehm. Die Veranstaltung fand im “InterContinental London” statt. Wie wir es von NETWAYS Veranstaltungen schon gewohnt sind, gab es reichlich zu Essen und zu Trinken, was uns nach der etwas längeren Anreise, doch zu Gute kam.

Als OpenSource Firma kommen wir bei NETWAYS immer mehr in Kontakt mit dem Configuration Management Tool Ansible. Bereits die ersten Kunden sind auf uns, eben wegen Ansible zugekommen und haben in Zusammenarbeit mit uns ihr Setup aufgebaut. Die Verwaltung der Produktivsysteme läuft demnach mit Ansible und diese Konfigurationen sind sowohl für uns als Administratoren als auch für den Kunden selbst mittels Git zugänglich. Falls auch ihr euch überlegt, eure Systeme mit Ansible zu verwalten, dann kommt gerne auf uns zu! Wir helfen gerne.

Zum Abschluss sind hier noch Bilder vom Hotel sowie von der Anreise hinterlegt.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

GitLab CE: Continuous Integration, Jobs and Runners

NWS GitLab CE Hosting Zur Verwaltung von auf git basierenden Projekten bietet GitLab CE neben Issue Tracker und Wiki auch eine Continuous Integration (CI) Umgebung. Pro Projekt kann eine CI-Konfiguration mit Job Definitionen gesetzt werden, welche nach jedem Commit von sogenannten GitLab Runner ausgeführt werden.  Die klassische CI-Pipeline (vom Build bis zum Deploy) kann mit Hilfe von Stages abgebildet werden. Die CI-Konfiguration wird als Datei (.gitlab-ci.yml) im Projekt mit abgespeichert.

 

Im folgendem ein kleines Beispiel welches einen GitLab Runner mit Docker Executor verwendet:

.gitlab-ci.yml

image: debian:latest
stages:
  - build
  - test
  - deploy

job1:
  stage: build
  script: 'ping -c 4 nws.netways.de'

job2:
  stage: test
  script: 'ping -c 4 netways.de'

job3:
  stage: deploy
  script: 'echo "deploying"'

after_script:
  - 'echo "do some housekeeping"'

 

Mit jedem Commit im Projekt werden die definierten Stages build, test und deploy und deren Jobs durchlaufen und von GitLab CE natürlich auch schön visualisiert wird.

This slideshow requires JavaScript.

GitLab Runner können verschiedene Executor haben, beginnend mit der klassischen Shell über Parallels hinzu Docker und Kubernetes. Wem das alles zu viel ist kann auch unsere vorkonfiguriertes GitLab CE mit Runner ausprobieren oder bei unserem Manged Services nach einem maßgeschneidertem Angebot nachfragen.

Achim Ledermueller

Autor: Achim Ledermueller

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.

NETWAYS Web Services: GitLab CE Hosting

This entry is part 2 of 8 in the series NETWAYS Web Services

GitLab CE HostingGitLab CE (Community Edition) ist die frei verfügbare Variante von GitLab, welche alle wichtigen Features von GitLab in einer Open Source Version vereint. GitLab bietet eine webbasierte Oberfläche für Softwareprojekte auf Basis der Versionsverwaltung git. Dazu verfügt GitLab über diverse Management und Bug-Tracking-Funktionalitäten, sowie mit GitLab CI ein System zur kontinuierlichen Integration.

NETWAYS bietet das Hosting von GitLab CE in unserer NETWAYS Web Services an. Wir übernehmen hier nicht nur die Installation und Konfiguration, sondern auch den kompletten Betrieb inkl. regelmäßiger Updates auf die aktuellste Version. Unser Angebot wird verteilt über zwei Rechenzentren in Nürnberg gehostet und betrieben. Somit stellen wir einen sicheren und zuverlässigen Service an einem (sehr schönen) Standort in Deutschland zur Verfügung.

GitLab CE

Alle GitLab CE Instanzen laufen isoliert in einem eigenen Container und alle nötigen Ressourcen sind exklusiv für Ihr Projekt reserviert. Und bei uns sind die GitLab Runner schon mit dabei!

Und wie gewohnt bei NWS – Sie können GitLab CE bei uns 30 Tage kostenfrei testen. Jetzt schnell anmelden!

 

Martin Krodel

Autor: Martin Krodel

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Contributing to projects on GitHub

GitHub Logo

Today I want to share my workflow for contributing to projects hosted on GitHub because I believe it works very well for me and I regularly contribute to various projects. Of course most of this also applies to other hosted Git platforms like GitLab. It will not involve any Git magic as there are other posts to do that. So let’s use adding a check command to Icinga 2 as my example.

The obvious first step is finding the Git repository for the project and reading contribution guidelines because there are some projects which aren’t hosted on GitHub and some have additional requirements like submitting an issue in addition to a pull request. You should always familiarize yourself with and stick to those policies if you want your pull request to be accepted. For Icinga 2 there currently aren’t any additional project-specific guidelines.

Your next step is to create a fork on GitHub and clone the repository. So in the GitHub web interface click on “Fork” and select your own account (or company account as long as you are allowed to push). Once you’ve forked the repository you can check out a local copy using the following command:


git clone git@github.com/dgoetz/icinga2.git

Afterwards you should add another “remote” for the original Git repository in order to be able to update your own repository with changes from the upstream project:


cd icinga2/
git remote add upstream git@github.com:icinga/icinga2.git

After these initial steps you can create a Git branch for your feature or bug fix. Using the “master” branch for pull requests is strongly discouraged because things tend to get complicated once you have more than one pull request. Another recommendation is to use branch names that match the upstream repository’s style. This however is not a hard requirement:


git checkout -b feature/expand-check-foo

This also automatically switches to the newly-created branch which means you can now start to edit files for your pull request. Once you’re done you can add them to the Git index and create a commit. Typically upstream projects have guidelines for this, so do not forget to include documentation, make only one commit out of your work (perhaps by squashing) and so on.


vi itl/plugins-contrib.d/network-components.conf
vi doc/10-icinga-template-library.md
git add itl/plugins-contrib.d/network-components.conf doc/10-icinga-template-library.md
git commit -m "ITL: expanded check foo"

Afterwards push your commit to your forked repository and then create your pull request using the GitHub webinterface:


git push -u origin feature/expand-check-foo

When creating the pull request make sure to provide a detailed description of your changes and the reason why you feel that your pull request should be merged. Keep the setting checked to allow edits from maintainers. Depending on the project make sure to reference any related issues, fill in their pull request template or do whatever else they require for pull requests.

GitHub pull request

Typically once a pull request is created automated tests will be run and a review process by the project team will start, so it’s possible that you’ll be asked to make changes before your pull request is accepted. If this happens simply edit your branch to fix whatever problems were found during the review, amend your commit and force push it to your fork. This will also automatically update your pull request but you might want to provide a comment for the pull request as to what has changed:


vi doc/10-icinga-template-library.md
git add doc/10-icinga-template-library.md
git commit --amend -m "ITL: expanded check foo"
git push -f

Another commonly requested change is that you rebase your branch before the pull request is accepted. This usually happens when significant changes were made to the upstream repository while your pull request was waiting to be merged. In order to rebase your branch the following commands should be all you need, however in some cases you may also have to manually resolve conflicts:


git pull --rebase upstream master
git push -f

And of course you will sometimes want to create additional pull requests. For these make sure to start with a new branch based on the upstream repository:


git checkout master
git pull upstream master
git checkout -b fix/check-bar
...
git push -u origin fix/check-bar

So, this is it, this is my basic workflow for easy contributions on GitHub. I hope it helps you to get involved with your favorite projects and your fixes and features to get upstream. If you prefer to do all step in the command line, you can have a look at GitHub’s command-line wrapper for git hub. If you need more general Git knowledge I recommend the Git book and our training. If you need a GitLab system to play around, have a look at our NWS platform.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet 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.

Authentication with OAuth

It’s pretty safe to say, that everyone using the web has already made an account for some website. For the broad masses the most common ones would be social media sites like facebook, youtube and twitter. Then there are also online shopping platforms like e-bay and amazon, and more techie orientated pages like stack overflow and all sorts of version control repositories.
(And of course various others for anything and everything else…)

Third party applications often allow you to sign in with your account from another website.

The good thing is, that you don’t need to create a separate account for every single one, but are offered the possibility to just sign in with an account you created for a different service.

The page for which you want to use a different account needs to request data from the original website and use it to authenticate the user (without their input).
In order to give both the requesting website and the user assurance that the data will be safe and reliable some sort of standardisation is required.

Most commonly used is the open standard for authorisation OAuth.
With OAuth it is possible for users to grant access to their information from a certain website without giving away their credentials.

This is what it looks like when the user reviews the permissions.

In order for the third party application to obtain specific information about a user, it has to request an access token from the authorisation server, and when the user grants the permission, use that token to access the resources from the website.

In our specific case we want users to be able to log in to Icinga Exchange with their GitHub accounts.

If you now also want to integrate GitHub on your website and/or see how it’s done: they have a detailed tutorial here.

Jennifer Mourek

Autor: Jennifer Mourek

Jennifer hat sich nach Ihrem Abitur erst einmal die große weite Welt angesehen, ehe es sie für Ihre Ausbildung zur Fachinformatikerin für Anwendungsentwicklung ab September 2016 nach Nürnberg zu NETWAYS verschlagen hat. Die Lieblingsfreizeitaktivitäten der gebürtigen Steigerwalderin sind das Zocken, Bouldern und sich mit Freunden und Kollegen auf gemütliche Spiele- und Filmabende zu treffen.

Monthly Snap November > Icinga 2 Director, OSMC, HW group Updates, AVTECH, Request Tracker, Foreman, Ceph, Git, Icinga 2 API, Braintower

SnspIn November, Thomas Gelf began with announcing the Icinga Director 1.2.0 release.

Isabel informs about new HW group Updates and the new Firmware for AVTECH Room Alert 3E.

Then Julia H. said thank you to our OSMC sponsors and wrote about why to join the OSMC Hackathon

Jennifer told us why we visualize while Markus Waldmüller presents the auto-provisioning with Foreman

Furthermore, Michael reviewed the PuppetConf in San Diego and told why Git Squash is magic.

Christian announced our availability of Request Tracker starter packages and Martin K. informed what to know about the Puppet Enterprise 3.8 End of Life

Towards the end of November, Tobias gave an Icinga 2 API Cheat Sheet, while Tim gave a Ceph training review.

Finally, Isabel wrote about the new Braintower Software and Updates.

 

 

Julia Hackbarth

Autor: Julia Hackbarth

Julia hat 2017 ihre Ausbildung zum Office Manager bei NETWAYS absolviert und währenddessen das Events&Marketing Team kennen und lieben gelernt. Besondere Freude bereiten ihr bei NETWAYS die tolle Teamarbeit und vielseitige Herausforderungen. Privat nutzt Julia ihre freie Zeit, um so oft wie möglich über's Handballfeld zu flitzen und sich auszutoben. In ihrer neuen Rolle als Marketing Managerin freut sie sich auf spannende Aufgaben und hofft, dass ihr die Ideen für kreative Texte nicht so schnell ausgehen.