DOCSLIB.ORG

Continuous Delivery of Continuous Delivery

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Continuous Delivery of Continuous Delivery CONTINUOUS DELIVERY OF CONTINUOUS DELIVERY Gerd Aschemann TUTORIAL / SCHULUNG Gerd Aschemann [email protected] http://aschemann.net twitter: @GerdAschemann Slack: https://jvm­german.slack.com/ (Channel: #build- systems) AGENDA Vagrant-Setup! Stufe 0: Motivation/Setup/Architektur… (45 Min) Stufe 1: Von der eigenen VagrantBox zum Build-Server und zurück (60 + 30 Min) Stufe 2: Aufbau Jenkins (60 Minuten) Stufe 3: Automatisierung Jobs (90 Minuten) Stufe 4: Miniprojekt mit SCM-Manager und Maven Release (60 Minuten) Abschluß: Diskussion/Kleinere Ergänzungen/Ausblick/Feedback (15 Minuten) Ein großer Teil der Umsetzung wird im Laufe des Tutorials als Git- Repository bereitgestellt! MOTIVATION Einführung/Vorstellungsrunde, 10 Min.) Setup (Vagrant, 10 Min.) Continuous Delivery (5 Min.) Architektur (20 Min.) SETUP (VAGRANT + VIRTUALBOX) Details folgen später! Vagrant Install Vagrant Init Vagrant Start Vagrant SSH Vagrant Destroy VAGRANT INSTALL Download (Vagrant + VirtualBox) + Installation gemäß Anleitung(en) https://www.vagrantup.com/downloads.html https://www.virtualbox.org/wiki/Downloads Alternative: Installation über Package Manager Debian/Ubuntu: [sudo] apt-get install vagrant virtualbox VAGRANT INIT Arbeitsverzeichnis anlegen, z.B. demo, und Vagrant initialisieren $ mkdir demo $ cd demo $ vagrant init -f bento/ubuntu-16.04 lädt Image und erzeugt eine Datei Vagrantfile # -*- mode: ruby -*- # vi: set ft=ruby : # All Vagrant configuration is done below. The "2" in Vagrant.configure ... Vagrant.configure(2) do |config| # ... config.vm.box = "bento/ubuntu-16.04" ... VAGRANT START Vagrant wird gestartet mit $ vagrant up Erzeugt zahlreiche Ausgaben: Bringing machine 'default' up with 'virtualbox' provider... ==> default: Importing base box 'bento/ubuntu-16.04'... ... ==> default: Machine booted and ready! ==> default: Checking for guest additions in VM... ... ==> default: Mounting shared folders... ... VAGRANT SSH Anschließend kann man sich auf der VM einloggen $ vagrant ssh ... vagrant@vagrant-ubuntu-trusty-64:~$ Hier kann man nun als Benutzer vagrant arbeiten, privilegierte Operationen können mit sudo ausgeführt werden, z.B. vagrant $ sudo apt-get install screen Das Arbeitsverzeichnis (demo) wird als /vagrant in die VM eingeblendet (Datei-Austausch, Provisionierung, … ) VAGRANT STOP / DESTROY Nach dem Ausloggen (oder von einer anderen Shell) kann man die VM zerstören: $ vagrant destroy Oder auch nur anhalten $ vagrant suspend Und weiterlaufen lassen $ vagrant resume WAS IST CONTINUOUS DELIVERY? Frei nach Martin Fowler Software ist jederzeit deploybar Deploybarkeit hat Vorrang vor Erweiterungen Aussagefähigkeit über Production-readiness nach jedem Change Push-button Deployment beliebiger Versionen in beliebige Umgebungen Hohe Automatisierung Continuous Delivery ist NICHT Continuous Deployment! CONTINUOUS DELIVERY CYCLE (?) Build Deploy Cycle??? Release? Test CONTINUOUS DELIVERY CASCADE (???) no no Develop (OK?) yes (OK?) yes Int. Test UAT Production +Unit Test CONTINUOUS DELIVERY LOOP (!) Feedback (loop?) Develop Int. Test UAT Production +Unit Test RÜCKBLICK: DEVELOPMENT Development Code Build Test no (OK?) yes Commit/Push DEVELOPMENT NOCH EINFACHER Development Code Test no (OK?) yes Commit/Push CONFIGURATION MANAGEMENT Config Mgmt. Configure Test no (OK?) yes Use JENKINS SCM­MANAGER SO NICHT: PET BESSER SO: CATTLE CM SYSTEMATISCH: WAS FEHLT? Configuration Management am "lebenden Herzen" Feedback-Loop ist sehr kurz! Feedback-Loop ist sehr lang!? "Blood, Sweat, and Tears"-Management Keine systematische Qualitätssicherung! CM EBENEN Infrastruktur: OS/Linux (Windows, OSX, Android, Embedded, … ) Plattform: Build Server (Jenkins, Bamboo, Travis, … ) Source Code Repo (Apache/SVN, SCM­Manager, Gitlab, Github, … ) Artifact Repo (Nexus, Artifactory, … ) QS-Management (Findbugs/Checkstyle/PMD, Surefire/Failsafe, … Sonar Qube) Application: Maven, Gradle, … PLATFORM AS CODE (PAC) Vagrant Puppet (+ Shell + Perl) Jenkins (+ Maven) Docker/Nexus ZIEL­ARCHITEKTUR (VEREINFACHT) «Linux/Windows/OSX/...» Developer-PC develop local deploy PaC Development commit/push PaC DevOps-Engineer «Linux» Meta-Build-Server (james) check out PaC check out PaC Source Code Repository Operator deliver Jenkins deliver Test Prod DETAIL­VIEW: DEVELOPER DevOps-Engineer Change «Linux/Windows/OSX/...» DevOps-PC LocalDevelopment «Git» Test Test Local_Repository vagrant up / vagrant provision «Vagrant» LocalVM pull/checkout «Jenkins» upload/download «Nexus» «SCM-Manager» Jenkins Local Nexus Local SCM-Manager Local DETAIL­VIEW: META­BUILD­SERVER «Linux» Meta-Build-Server poll «SCM-Manager» Source Code Repository Jenkins check out Test «Git» Test Test Test_Repository vagrant up / vagrant provision «Vagrant» TestVM pull/checkout «Jenkins» upload/download «Nexus» «SCM-Manager» Jenkins_Test Nexus Test SCM-Manager_Test DETAIL­VIEW: PRODUKTION Operator pull/checkout «Linux» Production Server «Git» Production_Repository deploy deploy deploy pull/checkout «Jenkins» upload/download «Nexus» «SCM-Manager» Jenkins Production Nexus Production SCM-Manager Production VAGRANT Setup virtueller Maschinen Provider Lokal/On-Premise: VirtualBox, libvirt (Qemu/KVM), Parallels, VMware, … Cloud: AWS Provisioner Default: Shell Infrastruktur CM-Tools: Puppet, Chef, Ansible, SaltStack?, … VAGRANTFILE Ruby-Syntax Provider + Box Konfiguration Name Speicher Netzwerk (Port forwards) Dateisystem(e): /vagrant Provisioner VAGRANTFILE (SAMPLE) Vagrant.configure(2) do |config| # ... config.vm.box = "ubuntu/trusty64" config.vm.provider "virtualbox" do |vbox, override| vbox.name = "demo-jugf" vbox.memory = 2048 override.vm.network "private_network", ip: "192.168.50.17", virtualbox__intnet: true # Jenkins override.vm.network "forwarded_port", guest: 8080, host: "17080" # Nexus override.vm.network "forwarded_port", guest: 8081, host: "17081" ... STUFE 1: VAGRANT→GIT→SCM­ MANAGER→JENKINS Vagrant ins Git Git in den SCM-Manager Job in Jenkins anlegen Job ausführen VAGRANT→GIT Git Repository anlegen git init Vagrantfile einchecken git add Vagrantfile git commit -m'Vagrant started' Optional: .gitignore anlegen und einchecken (s.u.) GIT→SCM (ANLEGEN) Repository im SCM-Manager anlegen GIT→SCM (ZUGRIFFSRECHTE) Zugriffsrechte im SCM-Manager vergeben: Reiter: Permissions Account hinzufügen (+) Keine Gruppe (?) Name: demo Permissions: WRITE GIT→SCM (SCREENSHOT) PUSH LOCAL REPOSITORY Remote-Repository URL hinzufügen Jeder Nutzer/Gruppe bekommt ein eigenes Repository <reponame> git remote add origin http://demo@james:8082/scm/git/<reponame> User/Host/Port/Pfad beachten! Push des aktuellen Standes git push --set-upstream origin master JENKINS: JOB ANLEGEN Neuen Job tutorial-<reponame> als Freestyle project anlegen JENKINS: CHECKOUT AUS GIT Source Code Management: Git mit URL: http://localhost:8082/scm/git/<reponame>; Achtung: Ohne User! Ggf. anderer Host/Port? Credentials: jenkins/* (ggf. mit Add hinzufügen) JENKINS: CHECKOUT AUS GIT (SC) JENKINS: BUILD TRIGGER + ANSI COLOR Build-Trigger (ähnlich crontab-Eintrag) Poll-SCM: Schedule H/3 * * * * H/3 verteilt Minute gleichmäßig auf Stunde * verteilen Stunde/Tag/Monat/Wochentag Ansi-Color (Plugin) wg. Vagrant JENKINS: BUILD TRIGGER + ANSI COLOR (SC) JENKINS: BUILD EXECUTE SHELL Build Execute shell Aktuell nur vagrant up Save! JENKINS: BUILD EXECUTE SHELL (SC) JENKINS: FERTIGER JOB Let’s Go: Build Now JENKINS: CONSOLE OUTPUT DISKUSSION 1A Wie unterscheiden wir verschiedene Instanzen in der VBox? DISKUSSION 1B Was passiert bei erneutem Start? DISKUSSION 1C Wie kommt man von außen auf die VM? Wie stoppt man die VM? STUFE 1A: VAGRANT­BOXEN MIT NAMEN Vagrantfile Vagrant.configure(2) do |config| config.vm.box = "bento/ubuntu-16.04" config.vm.hostname = 'tutorial-<reponame>' // (1) config.vm.provider "virtualbox" do |config| config.name = "tutorial-<reponame>" // (2) end end 1 Der Hostname ist nicht der Name der VirtualBox 2 Hier bekommt die Box einen Namen, das Setzen ist abhängig vom Provider AUSFLUG: IGNORIEREN VON DATEIEN FÜR GIT Kleiner Tipp für git: Datei .gitignore mit z.B. .vagrant/ anlegen und einchecken: .gitignore .vagrant/ $ git add .gitignore $ git commit -m'Ignore local vagrant files' STUFE 1B: RE­BUILD IM JENKINS? Problem: Box läuft schon im Jenkins Symptom: vagrant up macht nichts Lösung: Vor dem vagrant up noch ein vagrant destroy -f ausführen STUFE 1C: WIE KOMMT MAN VON AUSSEN AUF DIE BOX? Per Port-Mapping kann man die Box von außen erreichen (neben dem dynamischen Mapping des ssh-Ports)? Vagrantfile Vagrant.configure(2) do |config| config.vm.box = "bento/ubuntu-16.04" config.vm.hostname = 'demo' config.vm.provider "virtualbox" do |config, override| // (1) config.name = "demo" # SSH access override.vm.network "forwarded_port", guest: 22, host: "10022" // (1) end end 1 override beachten! Wenn alle den gleichen Port nehmen, haben wir im Jenkins ein Problem! PROVISIONIERUNG MIT VAGRANT PER SHELL Vagrant kann nach Start der VM eine weitere Provisionierung durchführen. Vagrantfile Vagrant.configure(2) do |config| config.vm.box = "bento/ubuntu-16.04" config.vm.hostname = 'demo' config.vm.provider "virtualbox" do |config, override| config.name = "demo" # SSH access override.vm.network "forwarded_port", guest: 22, host: "10022" end config.vm.provision "shell", path: "apt-update.sh" // (1) end 1 Beispielsweise kann ein Shell-Skript ausgeführt werden: PROVISION: APT-GET UPDATE … apt-update.sh #!/bin/bash set -eu sudo apt-get update sudo apt-get -qq dist-upgrade PROVISIONIERUNG: ALTERNATIVEN Alternativen sind Puppet Chef Ansible Saltstack … OPTIMIERUNG: APT­CACHE IN VAGRANT
Load more

Recommended publications
  • Configuration File Manipulation with Configuration Management Tools
    Configuration File Manipulation with Configuration Management Tools Student Paper for 185.307 Seminar aus Programmiersprachen, SS2016 Bernhard Denner, 0626746 Email: [email protected] Abstract—Manipulating and defining content of configuration popular CM-Tool in these days and offers a huge variety of files is one of the central tasks of configuration management configuration manipulation methods. But we will also take a tools. This is important to ensure a desired and correct behavior look at other CM-Tools to explore their view of configuration of computer systems. However, often considered very simple, this file handling. task can turn out to be very challenging. Configuration manage- ment tools provide different strategies for content manipulation In Section II an introduction will be given about CM- of files, hence an administrator should think twice to choose the Tools, examining which ones are established in the community best strategy for a specific task. This paper will explore different and how they work. Before we dive into file manipulation approaches of automatic configuration file manipulation with the strategies, Section III will give some introduction in configu- help of configuration management tools. We will take a close look at the configuration management tool Puppet, as is offers various ration stores. Section IV will describe different configuration different approaches to tackle content manipulation. We will also manipulation strategies of Puppet, whereas Section V will explore similarities and differences of approaches by comparing look at approaches of other CM-Tools. Section VI will show it with other configuration management tools. This should aid some scientific papers about CM-Tools.
    [Show full text]
  • Confex: a Framework for Automating Text-Based Software Configuration
    1 ConfEx: A Framework for Automating Text-based Software Configuration Analysis in the Cloud Ozan Tuncer, Anthony Byrne, Nilton Bila, Sastry Duri, Canturk Isci, and Ayse K. Coskun Abstract—Modern cloud services have complex architectures, often comprising many software components, and depend on hundreds of configurations parameters to function correctly, securely, and with high performance. Due to the prevalence of open-source software, developers can easily deploy services using third-party software without mastering the configurations of that software. As a result, configuration errors (i.e., misconfigurations) are among the leading causes of service disruptions and outages. While existing cloud automation tools ease the process of service deployment and management, support for detecting misconfigurations in the cloud has not been addressed thoroughly, likely due to the lack of frameworks suitable for consistent parsing of unstandardized configuration files. This paper introduces ConfEx, a framework that enables discovery and extraction of text-based software configurations in the cloud. ConfEx uses a novel vocabulary-based technique to identify configuration files in cloud system instances with unlabeled content. To extract the information in these files, ConfEx leverages existing configuration parsers and post-processes the extracted data for analysis. We show that ConfEx achieves over 99% precision and 100% recall in identifying configuration files on 7805 popular Docker Hub images. Using two applied examples, we demonstrate that ConfEx also enables detecting misconfigurations in the cloud via existing tools that are designed for configurations represented as key-value pairs, revealing 184 errors in public Docker Hub images. Index Terms—Software configuration, cloud, misconfiguration diagnosis. F 1 INTRODUCTION LOUD applications are designed in a highly config- Existing failure avoidance and mitigation mechanisms in C urable way to ensure high levels of reusability and the cloud (e.g., redundancy or recovery) are insufficient to portability.
    [Show full text]
  • Bidirectional Programming Languages
    University of Pennsylvania ScholarlyCommons Publicly Accessible Penn Dissertations Winter 2009 Bidirectional Programming Languages John Nathan Foster University of Pennsylvania, [email protected] Follow this and additional works at: https://repository.upenn.edu/edissertations Part of the Databases and Information Systems Commons, and the Programming Languages and Compilers Commons Recommended Citation Foster, John Nathan, "Bidirectional Programming Languages" (2009). Publicly Accessible Penn Dissertations. 56. https://repository.upenn.edu/edissertations/56 This paper is posted at ScholarlyCommons. https://repository.upenn.edu/edissertations/56 For more information, please contact [email protected]. Bidirectional Programming Languages Abstract The need to edit source data through a view arises in a host of applications across many different areas of computing. Unfortunately, few existing systems provide support for updatable views. In practice, when they are needed, updatable views are usually implemented using two separate programs: one that computes the view from the source and another that handles updates. This rudimentary design is tedious for programmers, difficult to reason about, and a nightmare to maintain. This dissertation presents bidirectional programming languages, which provide an elegant and effective mechanism for describing updatable views. Unlike programs written in an ordinary language, which only work in one direction, programs in a bidirectional language can be run both forwards and backwards: from left to right, they describe functions that map sources to views, and from right to left, they describe functions that map updated views back to updated sources. Besides eliminating redundancy, these languages can be designed to ensure correctness, guaranteeing by construction that the two functions work well together. Starting from the foundations, we define a general semantic space of well-behaved bidirectional transformations called lenses.
    [Show full text]
  • Zentrale Verwaltung Mit Facter, Puppet Und Augeas
    System-Management-Trio Zentrale Verwaltung mit facter, puppet und augeas Verwaltung mit facter, puppet und augeas © SpeedPartner GmbH Seite: 1 / 34 GUUG Frühjahrsfachgespräch, 01.03.2012 Über den Vortrag Aufbau / Ziele: ● Einführung / Überblick ● Begriffsklärung ● Aufbau / Arbeitsweise von Manifests ● Templates, Klassen, Typen, Module ● Facter: Umgebungsparameter ermitteln ● Augeas: Konfigurationen bearbeiten ● Client-Server-Betrieb ● Arbeit mit mehreren Umgebungen ● Links / Hilfen Verwaltung mit facter, puppet und augeas © SpeedPartner GmbH Seite: 2 / 34 GUUG Frühjahrsfachgespräch, 01.03.2012 Über mich ● Stefan Neufeind ● Mit-Geschäftsführer der SpeedPartner GmbH aus Neuss ein Internet-Service-Provider (ISP) ● Individuelle TYPO3-Entwicklungen ● Hosting, Housing, Managed Services ● Domains / Domain-Services ● IPv6, DNSSEC, ... ● Aktive Mitarbeit im Community-Umfeld (PHP/PEAR, TYPO3, Linux) ● Freier Autor für z.B. t3n, iX, Internet World, ... Verwaltung mit facter, puppet und augeas © SpeedPartner GmbH Seite: 3 / 34 GUUG Frühjahrsfachgespräch, 01.03.2012 Aufgabenstellung Alltägliche Administrationsaufgaben für ein (Server-)System Basisinstallation Fehler bei Ausführung von Zugänge „Standard-Aufgaben“? Backup Monitoring Fehlersuche / Einrichtung / Fehlerkorrektur Konzeptfehler? Konfiguration Netzwerk Fehler durch die Systemstatistiken „Sonderlösungen“? Architektur Virtuell? Individuelle Anpassungen Aufgaben RAID? Verwaltung mit facter, puppet und augeas © SpeedPartner GmbH Seite: 4 / 34 GUUG Frühjahrsfachgespräch, 01.03.2012 Aufgabenstellung
    [Show full text]
  • Rehearsal: a Configuration Verification Tool for Puppet
    Rehearsal: A Configuration Verification Tool for Puppet t* Rian Shambaugh Aaron Weiss Arjun Guha ac AE f Comp C i * let t nt e e * r t is W s University of Massachusetts Amherst, United States e n A l o l D C * * o * c I u e E s frian,aaronweiss,[email protected] m u D e e v n R L t e o a t d P y * s a E l u * a d t e Abstract 1. Introduction Large-scale data centers and cloud computing have turned Consider the role of a system administrator at any organi- system configuration into a challenging problem. Several zation, from a large company to a small computer science widely-publicized outages have been blamed not on soft- department. Their job is to maintain computing infrastruc- ware bugs, but on configuration bugs. To cope, thousands of ture for everyone else. When a new software system, such as organizations use system configuration languages to manage a Web service, needs to be deployed, it is their job to pro- their computing infrastructure. Of these, Puppet is the most vision new servers, configure the firewall, and ensure that widely used with thousands of paying customers and many data is automatically backed up. If the Web service receives more open-source users. The heart of Puppet is a domain- a sudden spike in traffic, they must quickly deploy additional specific language that describes the state of a system. Pup- machines to handle the load. When a security vulnerability pet already performs some basic static checks, but they only is disclosed, they must patch and restart machines if neces- prevent a narrow range of errors.
    [Show full text]
  • SM User Guide
    Oracle® Communications Tekelec Virtual Operating Environment Licensing Information User Manual Release 3.5 E93070-01 November 2017 Copyright ©2010, 2017 Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S.
    [Show full text]
  • Linuxtag 2012: System-Management-Trio Facter, Puppet Und Augeas
    System-Management-Trio Zentrale Verwaltung mit facter, puppet und augeas Verwaltung mit facter, puppet und augeas © SpeedPartner GmbH Seite: 1 / 33 LinuxTag, 23.05.2012 Über den Vortrag Aufbau / Ziele: ● Einführung / Überblick ● Begriffsklärung ● Aufbau / Arbeitsweise von Manifests ● Templates, Klassen, Typen, Module ● Facter: Umgebungsparameter ermitteln ● Augeas: Konfigurationen bearbeiten ● Client-Server-Betrieb ● Arbeit mit mehreren Umgebungen ● Links / Hilfen Verwaltung mit facter, puppet und augeas © SpeedPartner GmbH Seite: 2 / 33 LinuxTag, 23.05.2012 Über mich ● Stefan Neufeind ● Mit-Geschäftsführer der SpeedPartner GmbH aus Neuss ein Internet-Service-Provider (ISP) ● Individuelle TYPO3-Entwicklungen ● Hosting, Housing, Managed Services ● Domains / Domain-Services ● IPv6, DNSSEC, ... ● Aktive Mitarbeit im Community-Umfeld (PHP/PEAR, TYPO3, Linux) ● Freier Autor für z.B. t3n, iX, Internet World, ... Verwaltung mit facter, puppet und augeas © SpeedPartner GmbH Seite: 3 / 33 LinuxTag, 23.05.2012 Aufgabenstellung Alltägliche Administrationsaufgaben für ein (Server-)System Basisinstallation Fehler bei Ausführung von Zugänge „Standard-Aufgaben“? Backup Monitoring Fehlersuche / Einrichtung / Fehlerkorrektur Konzeptfehler? Konfiguration Netzwerk Fehler durch die Systemstatistiken „Sonderlösungen“? Architektur Virtuell? Individuelle Anpassungen Aufgaben RAID? Verwaltung mit facter, puppet und augeas © SpeedPartner GmbH Seite: 4 / 33 LinuxTag, 23.05.2012 Aufgabenstellung Herausforderungen bei Administration mehrerer Systeme ● Einsparungen
    [Show full text]
  • AUGEAS—A Configuration
    AUGEAS—a configuration API David Lutterkort Red Hat, Inc. [email protected] Abstract changing configuration files in a way that abstracts away the formatting details that are irrelevant to program- One of the many things that makes Linux configura- matic configuration changes. While formatting details tion management the minefield we all love is the lack may be irrelevant in this context, they are still impor- of a local configuration API. The main culprit for this tant, and AUGEAS goes through a lot of trouble to pre- situation, that configuration data is generally stored in serve comments, whitespace, etc. text files in a wide variety of formats, is both an impor- tant part of the Linux culture and valuable when humans Logic for configuration changes is embedded in many need to make configuration changes manually. tools, and the same logic is reinvented multiple times, often for no other reason than a difference in imple- AUGEAS provides a local configuration API that mentation language. As an example, Webmin [?] can presents configuration data as a tree. The tree is backed edit a wide variety of configuration files; that editing directly by the various config files as they exist today; logic, and the hard work for writing and maintaining it, modifications to the tree correspond directly to changes is of no use to other configuration tools like Puppet, in the underlying files. AUGEAS takes great care to pre- Bcfg2, or cfengine, since none of them is written in serve comments and other formatting details across edit- Perl. The prospect of reimplementing large parts of this ing operations.
    [Show full text]
  • NVIDIA Mellanox Onyx Software: End-User Agreement
    NVIDIA Mellanox Onyx Software: End-User Agreement NVIDIA Mellanox Onyx Software: End-User Agreement PLEASE READ THE FOLLOWING TERMS AND CONDITIONS OF THIS MELLANOX END USER LICENSE AGREEMENT (THIS "AGREEMENT") BEFORE INSTALLING OR USING THE NVDIA MELLANOX SOFTWARE. THE MELLANOX SOFTWARE, WHICH INCLUDES ALL COMPUTER SOFTWARE IN BINARY FORM THAT IS DELIVERED TO LICENSEE, GENERALLY DESCRIBED AS THE NVIDIA MELLANOX SWITCH ONYX SOFTWARE, AND ALL INTELLECTUAL PROPERTY RIGHTS THEREIN OR THERETO AND ANY ASSOCIATED MEDIA AND PRINTED MATERIALS, AND ANY "ONLINE" OR ELECTRONIC DOCUMENTATION, IS REFERRED TO HEREIN AS THE "SOFTWARE". INSTALLATION OR USAGE OF THE SOFTWARE INDICATES YOUR ACCEPTANCE OF THE TERMS OF THIS AGREEMENT, AND CREATES A LEGAL AND BINDING AGREEMENT BETWEEN YOU (EITHER AN INDIVIDUAL OR AN ENTITY) ("YOU" OR "LICENSEE") AND MELLANOX TECHNOLOGIES LTD. AND ITS AFFILIATES ("MELLANOX"). IF YOU DO NOT AGREE WITH THE TERMS AND CONDITIONS OF THIS AGREEMENT, YOU SHALL NOT USE OR COPY THIS SOFTWARE PRODUCT AND YOU MUST PROMPTLY RETURN THIS PACKAGE TO MELLANOX. 1 General Each copy of the Software is intended for use only in conjunction with NVIDIA Mellanox's managed switch products ("Mellanox Products") and is subject to the terms of this Agreement. 2 Grant of License Subject to the terms and conditions of this Agreement, Mellanox grants you a personal, non-exclusive, non- transferable license to use the Software in binary form for your internal business purposes solely in connection with Mellanox Products and not for further distribution. 2.1 Archive. You may use software back-up utilities to make one back-up copy of the Software Product.
    [Show full text]
  • Xutools: Unix Commands for Processing Next-Generation Structured Text
    Submitted for publication. Author Copy - do not redistribute. XUTools: Unix Commands for Processing Next-Generation Structured Text Gabriel A. Weaver Sean W. Smith Dartmouth College Dartmouth College Keywords: Text processing, Configuration Management, de meaningful structures via nested blocks. Natural- Change Management, Automation, Tools, Unix language documents may be divided up into chapters, paragraphs, and sentences. Sentences themselves may be Abstract further parsed. Configuration files and programming lan- guages, similarly, may be divided up into blocks of code. Traditional Unix tools operate on sequences of chara- For example, Cisco IOS interface blocks or C function cters, bytes, fields, lines, and files. However, modern blocks are information units that network administrators practitioners often want to manipulate files in terms of and developers reference daily. a variety of language-specific constructs—C functions, The prevalence of multi-line, nested-block-structured Cisco IOS interface blocks, and XML elements, to na- formats has left a capability gap for traditional tools. To- me a few. These language-specific structures quite often day, if practitioners want to extract interfaces from a Ci- lie beyond the regular languages upon which Unix text- sco IOS router configuration file, they must craft an invo- processing tools can practically compute. In this paper, cation for sed(1) we propose eXtended Unix text-processing tools (xuto- sed -n ’/ˆinterface ols) and present implementations that enable practitio- ATM0/,/ˆ!/\{/ˆ\!d;p;\}’ ners to extract (xugrep), count (xuwc), and compare (xudiff) texts in terms of language-specific structures. Using our xutools, practitioners need only type We motivate, design, and evaluate our tools around real- world use cases from network and system administrators, xugrep ’//ios:interface’ security consultants, and software engineers from a va- We designed and built eXtended Unix text-processing riety of domains including the power grid, healthcare, tools (xutools) so that practitioners could process files in and education.
    [Show full text]
  • Building Pipelines at Scale
    Jenkins User Conference Europe . Building Pipelines at Scale Julien Pivotto inuits.eu 25th June 2014 #jenkinsconf . Jenkins User Conference Europe . Building Pipelines at Scale . Introduction Who’s who Pipelines Puppet Why How Conclusion Plugins Why How Conclusion #jenkinsconf . Jenkins User Conference Europe . #jenkinsconf Julien Pivotto . Open-Source Consultant at inuits.eu Linux Systems Administrator FOSS Defender for many years DevOps Puppet user since 2011 Doing also some Ruby & Python Introduction/Who’s who . Jenkins User Conference Europe . #jenkinsconf inuits . Open-Source Consultancy company 50+ people in 4 countries (.be, .ua, .nl & .cz) Doing both Development & Systems Administration A lot of domains: Linux, Web, Databases, Monitoring… Early DevOps practitioners Introduction/Who’s who . Jenkins User Conference Europe . #jenkinsconf MediaMosa . Drupal-based Digital Asset Management system Open-source Store assets Transcode videos Create, extract and manage metadata using open standards: Dublin Core, Qualified DC, IEEE/LOM, CZP Webservice oriented Introduction/Who’s who . Jenkins User Conference Europe . #jenkinsconf MediaSalsa: MediaMosa As a Service . A turn-key MediaMosa solution A few environments: Dev/Uat/Prod environments Customer-specific environments One backend per environment Multiple frontends per backend = A lot of Drupal sites Introduction/Who’s who . Pipeline vs large (or independent) jobs: Separation between different tasks Overview of tests, etc… Deployment depends on testing Jenkins User Conference Europe . #jenkinsconf Definition of pipelines . A pipeline is a chain of Jenkins jobs that are run to fetch, compile, package, run tests and deploy an application (build pipeline plugin). Introduction/Pipelines . Jenkins User Conference Europe . #jenkinsconf Definition of pipelines . A pipeline is a chain of Jenkins jobs that are run to fetch, compile, package, run tests and deploy an application (build pipeline plugin).
    [Show full text]
  • Configuration Management with Libelektra
    Konfigurationsmanagement mit Libelektra DIPLOMARBEIT zur Erlangung des akademischen Grades Diplom-Ingenieur im Rahmen des Studiums Software Engineering - Internet Computing eingereicht von BSc. Bernhard Denner Matrikelnummer 0626746 an der Fakultät für Informatik der Technischen Universität Wien Betreuung: Ao.Univ.Prof.Dipl.-Ing. Dr.techn. Franz Puntigam Mitwirkung: Univ.Ass.Dipl.-Ing. Dr.techn. Markus Raab Wien, 16. Jänner 2018 Bernhard Denner Franz Puntigam Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Configuration Management with Libelektra DIPLOMA THESIS submitted in partial fulfillment of the requirements for the degree of Diplom-Ingenieur in Software Engineering - Internet Computing by BSc. Bernhard Denner Registration Number 0626746 to the Faculty of Informatics at the TU Wien Advisor: Ao.Univ.Prof.Dipl.-Ing. Dr.techn. Franz Puntigam Assistance: Univ.Ass.Dipl.-Ing. Dr.techn. Markus Raab Vienna, 16th January, 2018 Bernhard Denner Franz Puntigam Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Erklärung zur Verfassung der Arbeit BSc. Bernhard Denner Patzenthal 7, 2153 Stronsdorf Hiermit erkläre ich, dass ich diese Arbeit selbständig verfasst habe, dass ich die verwen- deten Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit – einschließlich Tabellen, Karten und Abbildungen –, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach entnommen sind, auf jeden Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht habe. Wien, 16. Jänner 2018 Bernhard Denner v Acknowledgements I would like to express my very great appreciation to my main supervisor Ao.Univ.Prof. Dipl.-Ing.
    [Show full text]