omnibus
v3.2.0
OmnibusDachprojekt : Chef Foundation
Projektzustand : aktiv
Probleme mit der Reaktionszeit maximal : 14 Tage
Anforderungszeitpunktzeit maximal : 14 Tage
Erstellen Sie einfach Full-Stack-Installateure für Ihr Projekt auf verschiedenen Plattformen.
Seth Chisamore und Christopher Maier von Küchenchef hielten bei Chefconf 2013 einen Einführungsgespräch über Omnibus mit dem Titel Eat The G gesamte Schüssel: Bauen eines Full-Stack-Installateurs mit Omnibus :
Dieses Projekt wird vom Chef -Release -Engineering -Team verwaltet. Weitere Informationen zum Beitrag, des Triage und des Veröffentlichungsprozesses des Release Engineering Teams finden Sie im Chef Release Engineering OSS Management Guide.
Omnibus ist so konzipiert, dass er mit einem minimalen Satz von Voraussetzungen ausgeführt wird. Sie benötigen Folgendes:
Omnibus bietet sowohl eine DSL für die Definition von Omnibus-Projekten für Ihre Software als auch ein Befehlszeilen-Tool zum Generieren von Installationsprojekten aus dieser Definition.
Installieren Sie Omnibus vor Ort auf Ihrer Workstation.
$ gem install omnibusSie können jetzt ein Omnibus -Projekt in Ihrem aktuellen Verzeichnis erstellen, indem Sie die Funktion für Projektgenerator verwenden.
$ omnibus new $MY_PROJECT_NAME Dies generiert ein vollständiges Projektskelett im Verzeichnis omnibus-$MY_PROJECT_NAME
Standardmäßig wird ein Verzeichnis namens omnibus-$MY_PROJECT_NAME unter der Annahme, dass Sie Ihre Omnibus-Konfiguration vom Repo getrennt halten. Es ist jedoch eine gängige Praxis, dieses Verzeichnis in omnibus umzubenennen und in die oberste Ebene Ihres Projekts Quell -Repo umzubenennen.
$ cd omnibus- $MY_PROJECT_NAME
$ bundle install --binstubsWeitere Details finden Sie in der Readme -Datei des generierten Projekts.
Omnibus bestimmt die Plattform, auf der ein Installationsprogramm basierend auf der Plattform erstellt werden soll, auf der es derzeit ausgeführt wird . Das heißt, Sie können nur eine .deb Datei auf einem debianbasierten System generieren. Um diese Einschränkung zu lindern, enthält das generierte Projekt ein Testküchen -Setup, das für die Erzeugung einer Reihe von Omnibus -Projekten geeignet ist.
Obwohl das Vorlagenprojekt aufbauen wird, wird es nichts Aufregendes tun. Dafür müssen Sie die Omnibus DSL verwenden, um die Besonderheiten Ihrer Anwendung zu definieren.
Wenn Omnibus vorhanden ist, verwendet Omnibus eine Konfigurationsdatei auf der obersten Ebene mit dem Namen omnibus.rb am Stamm Ihres Repositorys. Diese Datei wird zur Laufzeit geladen und enthält eine Reihe von Konfigurations -Tunables. Hier ist ein Beispiel:
# Build locally (instead of /var)
# -------------------------------
base_dir './local'
# Disable git caching
# ------------------------------
use_git_caching false
# Enable S3 asset caching
# ------------------------------
use_s3_caching true
s3_bucket ENV [ 'S3_BUCKET' ]
# There are three ways to authenticate to the S3 bucket
# 1. set `s3_access_key` and `s3_secret_key`
s3_access_key ENV [ 'S3_ACCESS_KEY' ]
s3_secret_key ENV [ 'S3_SECRET_KEY' ]
# 2. set `s3_profile` to use an AWS profile in the Shared Credentials files
#s3_profile ENV['S3_PROFILE']
# 3. set `s3_iam_role_arn` to use an AWS IAM role
#s3_iam_role_arn ENV['S3_IAM_ROLE_ARN'] Weitere Informationen finden Sie in der Config .
Sie können Omnibus angeben, eine andere Konfigurationsdatei zu laden, indem Sie die Option --config an einen beliebigen Befehl übergeben:
$ bin/omnibus --config /path/to/config.rb Schließlich können Sie eine bestimmte Konfigurationsoption in der Befehlszeile über das Flag --override überschreiben. Dies hat ultimative Vorrang vor Konfigurationsdateiwerten:
$ bin/omnibus --override use_git_caching:falseEine Projekt -DSL -Datei definiert Ihre tatsächliche Anwendung. Dies ist das, wofür Sie in erster Linie ein Installationsprogramm für den Full-Stack erstellen. Es bietet die Möglichkeit, die Abhängigkeiten des Projekts zu definieren (wie in Software -DSL -Definitionsdateien angegeben) sowie Möglichkeiten zum Festlegen von Installationspaket -Metadaten.
Alle Projektdefinitionen müssen im config/projects Ihres Omnibus -Repositorys enthalten sein.
name "chef-full"
maintainer "YOUR NAME"
homepage "http://yoursite.com"
install_dir "/opt/chef"
build_version "0.10.8"
build_iteration 4
dependency "chef"Einige verfügbare DSL -Methoden umfassen:
| DSL -Methode | Beschreibung |
|---|---|
name | Der Name des Projekts |
install_dir | Die gewünschte Installation des Pakets |
build_version | Die Paketversion |
build_iteration | Die Paket -Iterationsnummer |
dependency | Eine von Omnibus Software definierte Komponente, die in dieses Paket aufgenommen wird |
package | Rufen Sie eine Packager-spezifische DSL auf |
compress | Rufen Sie eine kompressorspezifische DSL auf |
Standardmäßig wird ein Zeitstempel an die Build_version angehängt. Sie können dieses Verhalten ausschalten, indem Sie append_timestamp in Ihrem omnibus.rb auf false einstellen oder in der Befehlszeile --override append_timestamp:false .
Weitere Informationen finden Sie in der Project .
Omnibus "Software" -Dateien definieren einzelne Softwarekomponenten, die Ihr Gesamtpaket erstellen. Sie sind die Bausteine Ihrer Bewerbung. Die Software DSL bietet eine Möglichkeit, zu definieren, wo die Softwarequellen abgerufen werden sollen, wie sie erstellt werden und welche Abhängigkeiten sie haben. Diese Abhängigkeiten sind auch in ihren eigenen Software-DSL-Dateien definiert, wodurch die Grundlage für eine Abhängigkeitsgerichts-Build-Bestellung bildet.
Alle Software -Definitionen sollten in das config/software Ihres Omnibus -Projektrepositorys eingehen.
Hier ist ein Beispiel:
name "ruby"
default_version "1.9.2-p290"
source url : "http://ftp.ruby-lang.org/pub/ruby/1.9/ruby- #{ version } .tar.gz" ,
md5 : "604da71839a6ae02b5b5b5e1b792d5eb"
dependency "zlib"
dependency "ncurses"
dependency "openssl"
relative_path "ruby- #{ version } "
build do
command "./configure"
command "make"
command "make install"
endEinige der verfügbaren DSL -Methoden umfassen:
| DSL -Methode | Beschreibung |
|---|---|
name | Der Name der Softwarekomponente (dies sollte zuerst kommen) |
default_version | Die Version der Softwarekomponente |
source | Wegbeschreibung zum Ort der Quelle |
dependency | Eine Omnibus-Software-definierte Komponente, von der diese Software abhängt |
relative_path | Der relative Weg des extrahierten Tarballs |
build | Die Build -Anweisungen |
Weitere DSL -Methoden finden Sie in der Software -Dokumentation.
Darüber hinaus sind im build -Block eine Reihe von DSL -Methoden verfügbar:
| DSL -Methode | Beschreibung |
|---|---|
command | Führen Sie einen einzelnen Shell -Befehl aus |
make | Rennen Sie make (mit oder ohne Argument |
patch | Wenden Sie einen Patch von der Festplatte an |
workers | Die maximale Anzahl von Bauherren |
windows_safe_path | Formatieren Sie den Weg, um sicher für den Schuss unter Windows zu sein |
go | Führen Sie den Code als eingebettete GO aus |
ruby | Führen Sie den Code als den eingebetteten Rubin aus |
gem | Führen Sie den Code als eingebettete Rubygemems aus |
bundle | Führen Sie den Code als den eingebetteten Bundler aus |
rake | Führen Sie den Code als eingebettetes Rake -Edelstein aus |
block | Führen Sie Ruby Block zur Bauzeit aus |
erb | Rendern Sie die gegebene ERB -Vorlage |
mkdir | Erstellen Sie das angegebene Verzeichnis |
touch | Erstellen Sie die angegebene leere Datei |
delete | Entfernen Sie die angegebene Datei oder das angegebene Verzeichnis |
strip | Streifen Sie Symbole aus Binärdateien in einer bestimmten Datei oder einem bestimmten Verzeichnis |
copy | Kopie a nach b |
move | Bewegen Sie A nach B |
link | Link a zu b |
sync | Kopieren Sie alle Dateien von A nach B und entfernen Sie alle Gewerkschaftsdateien |
Weitere DSL -Methoden finden Sie in der Builder -Dokumentation.
Sie können das Erstellen mehrerer Versionen derselben Software in derselben Software -Definitionsdatei mithilfe der version unterstützen und einen Block geben:
name "ruby"
default_version "1.9.2-p290"
version "1.9.2-p290" do
source url : "http://ftp.ruby-lang.org/pub/ruby/1.9/ruby- #{ version } .tar.gz" ,
md5 : "604da71839a6ae02b5b5b5e1b792d5eb"
end
version "2.1.1" do
source url : "http://ftp.ruby-lang.org/pub/ruby/2.1/ruby- #{ version } .tar.gz" ,
md5 : "e57fdbb8ed56e70c43f39c79da1654b2"
endDa die Software -Definitionen einfach Ruby Code sind, können Sie alles ausführen, indem Sie es mit reinem Ruby einwickeln, der auf die Versionsnummer testet.
Der einfachste Weg, organisationsweite Software auszutauschen, ist über Bundler und Rubygems. Für ein Beispiel-Software-Repository sehen Sie sich die Omnibus-Software des Chefkochs an. Weitere Informationen finden Sie in der Dokumentation von Rubygemems.
Es wird empfohlen, dass Sie Bundler verwenden, um diese Edelsteine abzuziehen (da Bundler auch das Ziehen von Software direkt von GitHub ermöglicht):
gem 'my-company-omnibus-software'
gem 'omnibus-software' , github : 'my-company/omnibus-software' Fügen Sie dann den Namen der Software in die Liste der software_gems in Ihrer Omnibus -Konfiguration hinzu:
software_gems %w( my-company-omnibus-software omnibus-software )Sie können auch lokale Wege auf der Festplatte angeben (jedoch werden Sie gewarnt, dies kann das Teilen des Projekts unter Teams erschweren):
local_software_dirs %w( /path/to/software /other/path/to/software ) Für all diese Pfade ist Auftragsangelegenheiten , daher ist es möglich, von der lokalen Softwareversion abhängig zu sein und gleichzeitig ein Remote -Software -Repo beizubehalten. Angesichts des obigen Beispiels sucht Omnibus in dieser Reihenfolge nach einer Softwaredefinition mit dem Namen foo :
$PWD/config/software/foo.rb
/path/to/software/config/software/foo.rb
/other/path/to/software/config/software/foo.rb
/Users/sethvargo/.gems/.../my-company-omnibus-software/config/software/foo.rb
/Users/sethvargo/.gems/.../omnibus-software/config/software/foo.rb
Die erste Instanz von foo.rb auf die auftritt, wird verwendet. Bitte beachten Sie, dass lokale (verwendete) Softare -Definitionen Vorrang haben!
Sobald Sie Ihre Paket- und Software -Definitionen erstellt haben, können Sie mit:
./bin/omnibus build $MY_PACKAGE_NAMEEs gibt jedoch mehrere Vorbehalte, die Sie kennen müssen:
base_dir in omnibus.rb inkennt oder zumindest cache_dir und build_dir ändern, wie es sonst versucht, /var/cache/omnibus und /opt/$MY_PROJECT_NAME zu verwenden und Root zu erfordern.config/projects/$MY_PROJECT_NAME.rb aufgeführt sind. Sie können die Software .rb -Dateien, die im Ordner config/software vorhanden sind, verweisen.install_dir erfordert in der Regel zur Erstellung root . Ändern Sie es in einem anderen Ort wie "/tmp/#{name}" um zu vermeiden, dass sie als root ausgeführt werden.omnibus-software stammen. Sie Gemfile also diese verwenden/opt/$project/bin möchten, müssen Sie entweder AppBundler verwenden oder einen Post -Install -Schritt haben, um diese Binstubs zu erstellen.ruby angeben, müssen Sie auch rubygems und bundler überschreiben, um die Versionen in dieser Version von ruby abzustimmen, oder Sie erhalten Fehler in Bezug auf Bundler -Versionsfehler. Der obige Build -Befehl wird natürlich auf Ihrem lokalen Host aufbauen und so spezifisch für das Betriebssystem und das Basissystem sind, auf dem Sie sich befinden. Aber das Skeleting Setup von omnibus new bereits für Sie eingerichtet, so dass es einfach für eine Vielzahl von OSS erstellt werden kann, finden README.md in Ihrem generierten Omnibus -Verzeichnis, um Details zu erhalten.
GIT-basierte Softwaredefinitionen können Filialen als Standard_version angeben. In diesem Fall wird die genaue Git-Revision zum Bauzeit festgelegt, es sei denn, eine Überschreibung von Projekten (siehe unten) oder ein Manifest für externe Versionen wird verwendet. Um eine Version Manifest zu generieren, verwenden Sie den Befehl omnibus manifest :
omnibus manifest PROJECT -l warn
Dadurch wird ein JSON-formatiertes Manifest ausgegeben, das die aufgelöste Version jeder Software-Definition enthält.
Manchmal hat eine Plattform Bibliotheken, die whitelistet werden müssen, damit der HealthCheck passieren kann. Der im HealthCheck -Code gefundene Whitelist umfasst die minimalen, die für erfolgreiche Builds auf unterstützten Plattformen erforderlich sind.
Um Ihre eigene whitelistische Bibliothek hinzuzufügen, fügen Sie einfach eine Regex zu Ihrer Software -Definition in Ihrem Omnibus -Projekt hinzu: folgt:
whitelist_file /libpcrecpp.so..+/
Es ist in der Regel eine gute Idee, eine Bedingung der Whitelist basierend auf der spezifischen Plattform hinzuzufügen, die dies erfordert.
WARNUNG: Sie sollten nur Bibliotheken zum Whitelist hinzufügen, die garantiert auf dem System befinden, auf das Sie installieren. Wenn eine Bibliothek aus einem Nicht-Default-Paket stammt, sollten Sie sie stattdessen in das Paket aufbauen.
Status: experimentell
omnibus changelog generate wird einen ChangeLog für ein Omnibus -Projekt erzeugen. Dieser Befehl setzt derzeit an:
Diese Annahmen werden sich ändern, wenn wir bestimmen, was für eine Reihe unserer Projekte am besten funktioniert.
Die Projektdefinitionen können bestimmte Softwareabhängigkeiten überschreiben, indem sie in override übergeben, um die richtige Version zu verwenden:
name "chef-full"
# <snip>
# This will override the default version of "chef"
override :chef , version : "2.1.1"
dependency "chef"Die überragende Version muss in der zugehörigen Software definiert werden!
Standardmäßig loget sich Omnibus auf der warn an. Sie können dies überschreiben, indem Sie die Flagge- --log-level an Ihren Omnibus-Anruf übergeben:
$ bin/omnibus build < project > --log-level info # or "debug" Standardmäßig kompilierte Omnibus -Caches Software -Definitionen, sodass das N+1 -Omnibus -Projekt Builds viel schneller sind. Diese Funktionalität kann deaktiviert werden, indem Sie Folgendes zu Ihrem omnibus.rb hinzufügen:
use_git_caching false Informationen zum Beitrag zu diesem Projekt finden Sie unter https://github.com/chef/chef/blob/master/contributing.md
Copyright 2012-2016 Chef Software, Inc.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
