omnibus
v3.2.0
OmnibusProjet de parapluie : Fondation Chef
État du projet : actif
Problèmes Temps de réponse Maximum : 14 jours
Tirez le temps de réponse de la demande maximum : 14 jours
Créez facilement des installateurs complets pour votre projet sur une variété de plates-formes.
Seth Chisamore et Christopher Maier de Chef ont donné une conférence d'introduction sur Omnibus à Chefconf 2013, intitulé Eat The Whole Bowl: Construire un installateur complet avec Omnibus :
Ce projet est géré par l'équipe d'ingénierie du chef. Pour plus d'informations sur le processus de contribution, de triage et de publication de l'équipe d'ingénierie de publication, veuillez consulter le Guide de gestion de l'ingénierie de l'ingénierie du chef.
Omnibus est conçu pour fonctionner avec un ensemble minimal de conditions préalables. Vous aurez besoin de ce qui suit:
Omnibus fournit à la fois un DSL pour définir des projets omnibus pour votre logiciel, ainsi qu'un outil de ligne de commande pour générer des artefacts d'installation à partir de cette définition.
Pour commencer, installez omnibus localement sur votre poste de travail.
$ gem install omnibusVous pouvez désormais créer un projet omnibus dans votre répertoire actuel en utilisant la fonction de générateur de projet.
$ omnibus new $MY_PROJECT_NAME Cela générera un squelette complet de projet dans le répertoire omnibus-$MY_PROJECT_NAME
Par défaut, cela fera un répertoire appelé omnibus-$MY_PROJECT_NAME en supposant que vous gardez votre configuration omnibus séparée du référentiel. Cependant, le maintenir dans votre référentiel est une pratique courante, alors sentez-vous renommer ce répertoire à omnibus et le placer au niveau supérieur de votre récompense Source de projets.
$ cd omnibus- $MY_PROJECT_NAME
$ bundle install --binstubsPlus de détails peuvent être trouvés dans le fichier ReadMe du projet généré.
Omnibus détermine la plate-forme pour la construction d'un installateur en fonction de la plate-forme sur laquelle il fonctionne actuellement . Autrement dit, vous ne pouvez générer qu'un fichier .deb sur un système basé sur Debian. Pour atténuer cette mise en garde, le projet généré comprend une configuration de cuisine d'essai adaptée à la génération d'une série de projets omnibus.
Bien que le projet de modèle se développe, il ne fera rien d'excitant. Pour cela, vous devez utiliser l'Omnibus DSL pour définir les spécificités de votre application.
S'il est présent, Omnibus utilisera un fichier de configuration de niveau supérieur nommé omnibus.rb à la racine de votre référentiel. Ce fichier est chargé à l'exécution et comprend un certain nombre de tunables de configuration. Voici un exemple:
# 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'] Pour plus d'informations, veuillez consulter la documentation Config .
Vous pouvez dire à Omnibus de charger un fichier de configuration différent en passant l'option --config à n'importe quelle commande:
$ bin/omnibus --config /path/to/config.rb Enfin, vous pouvez remplacer une option de configuration spécifique sur la ligne de commande à l'aide de l'indicateur --override . Cela a une priorité ultime sur toutes les valeurs de fichier de configuration:
$ bin/omnibus --override use_git_caching:falseUn fichier DSL du projet définit votre application réelle; C'est la chose pour laquelle vous créez un programme d'installation complet en premier lieu. Il fournit un moyen de définir les dépendances du projet (encore une fois, comme spécifié dans les fichiers de définition DSL logiciels), ainsi que des moyens de définir les métadonnées du package d'installation.
Toutes les définitions de projet doivent être dans le répertoire config/projects de votre référentiel omnibus.
name "chef-full"
maintainer "YOUR NAME"
homepage "http://yoursite.com"
install_dir "/opt/chef"
build_version "0.10.8"
build_iteration 4
dependency "chef"Certaines méthodes DSL disponibles comprennent:
| Méthode DSL | Description |
|---|---|
name | Le nom du projet |
install_dir | L'emplacement d'installation souhaité du colis |
build_version | La version du package |
build_iteration | Le numéro d'itération du package |
dependency | Un composant défini par logiciel Omnibus à inclure dans ce package |
package | Invoquez un DSL spécifique au package |
compress | Invoquez un DSL spécifique au compresseur |
Par défaut, un horodatage est annexé à la build_version. Vous pouvez désactiver ce comportement en définissant append_timestamp sur false dans votre omnibus.rb ou en utilisant --override append_timestamp:false sur la ligne de commande.
Pour plus d'informations, veuillez consulter la documentation Project .
Les fichiers "logiciels" omnibus définissent les composants logiciels individuels qui consultent votre package global. Ce sont les éléments constitutifs de votre demande. Le logiciel DSL fournit un moyen de définir où récupérer les sources logicielles, comment les construire et quelles dépendances ils ont. Ces dépendances sont également définies dans leurs propres fichiers DSL logiciels, formant ainsi la base d'une commande de build conscient de dépendance.
Toutes les définitions de logiciels doivent être consacrées au répertoire config/software de votre référentiel de projet omnibus.
Voici un exemple:
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"
endCertaines des méthodes DSL disponibles comprennent:
| Méthode DSL | Description |
|---|---|
name | Le nom du composant logiciel (cela devrait venir en premier) |
default_version | La version du composant logiciel |
source | Directions à l'emplacement de la source |
dependency | Un composant défini par logiciel omnibus dont ce logiciel dépend |
relative_path | Le chemin relatif du tarball extrait |
build | Les instructions de construction |
Pour plus de méthodes DSL, veuillez consulter la documentation Software .
De plus, il existe un certain nombre de méthodes DSL disponibles dans le bloc build :
| Méthode DSL | Description |
|---|---|
command | Exécuter une seule commande shell |
make | Exécutez make (avec ou sans args), en utilisant GMake, le cas échéant |
patch | Appliquer un patch à partir du disque |
workers | Le nombre maximum de constructeurs |
windows_safe_path | Formater le chemin pour être sûr pour les bombardements sous Windows |
go | Exécuter le code comme le go intégré |
ruby | Exécuter le code comme le rubis intégré |
gem | Exécutez le code comme les rubygems intégrés |
bundle | Exécutez le code comme le bundler intégré |
rake | Exécutez le code comme la gemme Rake intégrée |
block | Exécuter Ruby Block au moment de la construction |
erb | Rendez le modèle ERB donné |
mkdir | Créer le répertoire donné |
touch | Créer le fichier vide donné |
delete | Supprimer le fichier ou le répertoire donné |
strip | Strip symboles de binaires sur un fichier ou un répertoire donné |
copy | Copier A à B |
move | Déplacer A à B |
link | Lier A à B |
sync | Copiez tous les fichiers de A à B, en supprimant tous les fichiers syndicaux |
Pour plus de méthodes DSL, veuillez consulter la documentation Builder .
Vous pouvez prendre en charge la création de plusieurs versions du même logiciel dans le même fichier de définition de logiciel à l'aide de la méthode version et donnant un bloc:
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"
endÉtant donné que les définitions de logiciels sont simplement du code Ruby, vous pouvez exécuter conditionnellement n'importe quoi en l'emballage avec du rubis pur qui teste le numéro de version.
Le moyen le plus simple de partager des logiciels à l'échelle de l'organisation est via Bundler et Rubygems. Pour un exemple de référentiel de logiciels, regardez les logiciels omnibus-logiciels du chef. Pour plus d'informations, veuillez consulter la documentation Rubygems.
Il est recommandé d'utiliser Bundler pour réduire ces gemmes (car Bundler permet également de retirer les logiciels directement de GitHub):
gem 'my-company-omnibus-software'
gem 'omnibus-software' , github : 'my-company/omnibus-software' Ajoutez ensuite le nom du logiciel à la liste de software_gems dans votre configuration omnibus:
software_gems %w( my-company-omnibus-software omnibus-software )Vous pouvez également spécifier des chemins locaux sur le disque (mais être averti que cela pourrait rendre le partage entre les équipes difficile):
local_software_dirs %w( /path/to/software /other/path/to/software ) Pour tous ces chemins, l'ordre compte , il est donc possible de dépendre de la version logicielle locale tout en conservant un référentiel logiciel distant. Compte tenu de l'exemple ci-dessus, Omnibus recherchera une définition de logiciel nommée foo dans cet ordre:
$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
La première instance de foo.rb rencontrée sera utilisée. Veuillez noter que les définitions locales (vendues) ont priorité!
Une fois que vous avez créé vos définitions de package et de logiciel, vous pouvez créer avec:
./bin/omnibus build $MY_PACKAGE_NAMECependant, il y a plusieurs mises en garde à savoir:
base_dir dans omnibus.rb , ou à tout le moins changer cache_dir et build_dir car sinon il essaiera d'utiliser /var/cache/omnibus et /opt/$MY_PROJECT_NAME , nécessitant une racine.config/projects/$MY_PROJECT_NAME.rb . Vous pouvez référer les fichiers logiciels .rb présents dans le dossier config/software .install_dir spécifiée dans le fichier de projet nécessite généralement un privilège root au moment de la construction. Changez-le un autre emplacement tel que "/tmp/#{name}" pour éviter de fonctionner comme root .omnibus-software . Vous souhaitez donc utiliser ceux dont vous aurez besoin pour l'incommer dans le Gemfile , ou le fourre-le, puis référer le vôtre/opt/$project/bin , vous devrez soit utiliser AppBundler, soit vous devrez avoir une étape d'installation de post pour créer ces bintubs.ruby , vous devrez également remplacer rubygems et bundler pour correspondre aux versions de cette version de ruby ou vous obtiendrez des échecs autour des non-matraques de version de Bundler. La commande de construction ci-dessus s'appuiera bien sûr sur votre hôte local, étant ainsi spécifique au système d'exploitation et du système de base sur lequel vous vous trouvez. Mais la configuration du squelette par omnibus new déjà configure pour vous afin qu'il soit facile à construire pour une variété d'Os, voir le README.md dans votre répertoire omnibus généré pour plus de détails.
Les définitions de logiciels basées sur GIT peuvent spécifier les branches comme leur valeur de défaut. Dans ce cas, la révision GIT exacte à utiliser sera déterminée au moment de la construction, sauf si une priorité de projet (voir ci-dessous) ou un manifeste de version externe est utilisée. Pour générer une version manifeste, utilisez la commande omnibus manifest :
omnibus manifest PROJECT -l warn
Cela sortira un manifeste Formaté JSON contenant la version résolue de chaque définition du logiciel.
Parfois, une plate-forme a des bibliothèques qui doivent être listes blanches afin que le HealthCheck puisse passer. La liste blanche trouvée dans le code HealthCheck comprend le minimum requis pour réussir des versions sur les plates-formes prises en charge.
Pour ajouter votre propre bibliothèque à liste blanche, ajoutez simplement un regex à votre définition de logiciel dans votre projet omnibus comme suit:
whitelist_file /libpcrecpp.so..+/
C'est généralement une bonne idée d'ajouter une liste blanche conditionnelle en fonction de la plate-forme spécifique qui l'exige.
AVERTISSEMENT: vous ne devez ajouter que des bibliothèques à la liste blanche qui sont garanties d'être sur le système sur lequel vous installez; Si une bibliothèque provient d'un package non défaut, vous devez plutôt le construire dans le package.
Statut: expérimental
omnibus changelog generate générera un Changelog pour un projet omnibus. Cette commande suppose actuellement:
Ces hypothèses changeront à mesure que nous déterminons ce qui fonctionne le mieux pour un certain nombre de nos projets.
Les définitions du projet peuvent remplacer les dépendances logicielles spécifiques en transmettant override pour utiliser la version correcte:
name "chef-full"
# <snip>
# This will override the default version of "chef"
override :chef , version : "2.1.1"
dependency "chef"La version remplacée doit être définie dans le logiciel associé!
Par défaut, Omnibus se connectera au niveau warn . Vous pouvez remplacer cela en passant l'indicateur --log-level à votre appel omnibus:
$ bin/omnibus build < project > --log-level info # or "debug" Par défaut, les définitions de logiciels compilées omnibus caches, donc les versions de projet N + 1 omnibus sont beaucoup plus rapides. Cette fonctionnalité peut être désactivée en ajoutant ce qui suit à votre omnibus.rb :
use_git_caching false Pour plus d'informations sur la contribution de ce projet
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.
