omnibus
v3.2.0
GeneralProyecto paraguas : Fundación Chef
Estado del proyecto : activo
Problemas Tiempo de respuesta máximo : 14 días
Tiempo de respuesta de solicitud de extracción máximo : 14 días
Cree fácilmente instaladores de pila para su proyecto en una variedad de plataformas.
Seth Chisamore y Christopher Maier de Chef dieron una charla introductoria sobre Omnibus en ChefConf 2013, titulado Eat The Whole Bowl: Construyendo un instalador de pila completa con Omnibus :
Este proyecto es administrado por el equipo de ingeniería de lanzamiento del chef. Para obtener más información sobre la contribución, el triaje y el proceso de lanzamiento del equipo de ingeniería de lanzamiento, consulte la Guía de gestión de OSS de Ingeniería de Lanzamiento de Chef.
Omnibus está diseñado para funcionar con un conjunto mínimo de requisitos previos. Necesitará lo siguiente:
Omnibus proporciona un DSL para definir proyectos Omnibus para su software, así como una herramienta de línea de comandos para generar artefactos del instalador a partir de esa definición.
Para comenzar, instale omnibus localmente en su estación de trabajo.
$ gem install omnibusAhora puede crear un proyecto Omnibus en su directorio actual utilizando la función del generador de proyectos.
$ omnibus new $MY_PROJECT_NAME Esto generará un esqueleto de proyecto completo en el directorio omnibus-$MY_PROJECT_NAME
Por defecto, esto hará un directorio llamado omnibus-$MY_PROJECT_NAME suponiendo que mantenga su configuración Omnibus separada del repositorio. Sin embargo, mantenerlo en su repositorio es una práctica común, así que siéntase a nombre de este directorio a omnibus y colocarlo en el nivel superior del repositorio de su fuente de proyectos.
$ cd omnibus- $MY_PROJECT_NAME
$ bundle install --binstubsSe pueden encontrar más detalles en el archivo ReadMe del proyecto generado.
Omnibus determina la plataforma para la cual construir un instalador basado en la plataforma en la que se ejecuta actualmente . Es decir, solo puede generar un archivo .deb en un sistema basado en Debian. Para aliviar esta advertencia, el proyecto generado incluye una configuración de cocina de prueba adecuada para generar una serie de proyectos omnibus.
Aunque el proyecto de plantilla se desarrollará, no hará nada emocionante. Para eso, debe usar el Omnibus DSL para definir los detalles de su aplicación.
Si está presente, Omnibus utilizará un archivo de configuración de nivel superior llamado omnibus.rb en la raíz de su repositorio. Este archivo se carga en tiempo de ejecución e incluye una serie de ajustes de configuración. Aquí hay un ejemplo:
# 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'] Para obtener más información, consulte la documentación Config .
Puede decirle a Omnibus que cargue un archivo de configuración diferente pasando la opción --config a cualquier comando:
$ bin/omnibus --config /path/to/config.rb Finalmente, puede anular una opción de configuración específica en la línea de comando usando el indicador --override . Esto toma precedencia final sobre cualquier valor de archivo de configuración:
$ bin/omnibus --override use_git_caching:falseUn archivo DSL del proyecto define su aplicación real; Esto es lo que está creando un instalador de pila completa en primer lugar. Proporciona un medio para definir las dependencias del proyecto (nuevamente, como se especifica en los archivos de definición DSL de software), así como formas de establecer metadatos del paquete de instalación.
Todas las definiciones del proyecto deben estar en el directorio config/projects de su repositorio 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"Algunos métodos DSL disponibles incluyen:
| Método DSL | Descripción |
|---|---|
name | El nombre del proyecto |
install_dir | La ubicación de instalación deseada del paquete |
build_version | La versión del paquete |
build_iteration | El número de iteración del paquete |
dependency | Un componente definido por software Omnibus para incluir en este paquete |
package | Invocar un DSL específico del paquete |
compress | Invocar un DSL específico del compresor |
Por defecto, se adjunta una marca de tiempo a la build_version. Puede desactivar este comportamiento configurando append_timestamp en false en su omnibus.rb o usando --override append_timestamp:false en la línea de comando.
Para obtener más información, consulte la documentación Project .
Los archivos de "software" de Omnibus definen componentes de software individuales que van a hacer su paquete general. Son los bloques de construcción de su aplicación. El software DSL proporciona una forma de definir dónde recuperar las fuentes de software, cómo construirlas y qué dependencias tienen. Estas dependencias también se definen en sus propios archivos DSL de software, formando así la base para un pedido de compilación consciente de la dependencia.
Todas las definiciones de software deben ir en el directorio config/software de su repositorio de proyecto Omnibus.
Aquí hay un ejemplo:
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"
endAlgunos de los métodos DSL disponibles incluyen:
| Método DSL | Descripción |
|---|---|
name | El nombre del componente de software (esto debería ser lo primero) |
default_version | La versión del componente de software |
source | Instrucciones a la ubicación de la fuente |
dependency | Un componente definido por software Omnibus en el que depende este software |
relative_path | El camino relativo del tarball extraído |
build | Las instrucciones de construcción |
Para obtener más métodos DSL, consulte la documentación Software .
Además, hay una serie de métodos DSL disponibles dentro del bloque build :
| Método DSL | Descripción |
|---|---|
command | Ejecutar un solo comando de shell |
make | Ejecutar make (con o sin args), usando gmake cuando sea apropiado |
patch | Aplicar un parche desde el disco |
workers | El número máximo de constructores |
windows_safe_path | Formatear la ruta para ser seguro para desembolsar en Windows |
go | Ejecutar el código como el GO incorporado |
ruby | Ejecutar el código como el ruby incrustado |
gem | Ejecutar el código como los rubygems incrustados |
bundle | Ejecutar el código como el Bundler integrado |
rake | Ejecutar el código como la gema de rastrillo integrado |
block | Ejecutar el bloque Ruby en la hora de construcción |
erb | Renderizar la plantilla ERB dada |
mkdir | Crea el directorio dado |
touch | Crea el archivo vacío dado |
delete | Eliminar el archivo o directorio dado |
strip | Desnectar símbolos de binarios en un archivo o directorio determinado |
copy | Copiar A a B |
move | Mover A a B |
link | Enlace A a B |
sync | Copiar todos los archivos de A a B, eliminar cualquier archivo de sindicato |
Para obtener más métodos DSL, consulte la documentación Builder .
Puede admitir la creación de múltiples versiones del mismo software en el mismo archivo de definición de software utilizando el método version y dar un bloque:
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"
endDado que las definiciones de software son simplemente código Ruby, puede ejecutar condicionalmente cualquier cosa envolviéndolo con Ruby puro que pruebe el número de versión.
La forma más fácil de compartir el software de toda la organización es a través de Bundler y Rubygems. Para obtener un repositorio de software de ejemplo, mire el software omnibus de Chef. Para obtener más información, consulte la documentación de Rubygems.
Se recomienda que use Bundler para derribar estas gemas (ya que Bundler también permite extraer software directamente de Github):
gem 'my-company-omnibus-software'
gem 'omnibus-software' , github : 'my-company/omnibus-software' Luego agregue el nombre del software a la lista de software_gems en su configuración omnibus:
software_gems %w( my-company-omnibus-software omnibus-software )También puede especificar rutas locales en el disco (pero tenga en cuenta que esto puede dificultar compartir el proyecto entre los equipos):
local_software_dirs %w( /path/to/software /other/path/to/software ) Para todas estas rutas, el pedido es importante , por lo que es posible depender de la versión de software local mientras conserva un repositorio de software remoto. Dado el ejemplo anterior, Omnibus buscará una definición de software llamada foo en este orden:
$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
Se utilizará la primera instancia de foo.rb que se encuentre. ¡Tenga en cuenta que las definiciones softales locales (Vendored) tienen prioridad!
Una vez que haya creado su paquete y definiciones de software, puede construir:
./bin/omnibus build $MY_PACKAGE_NAMESin embargo, hay varias advertencias a tener en cuenta:
base_dir en omnibus.rb , o al menos cambiar cache_dir y build_dir ya que de lo contrario intentará usar /var/cache/omnibus y /opt/$MY_PROJECT_NAME , requiriendo root.config/projects/$MY_PROJECT_NAME.rb . Puede referir los archivos .rb de software presentes en la carpeta config/software .install_dir especificado en el archivo del proyecto generalmente requiere privilegio root en la hora de compilación. Cámbielo otra ubicación como "/tmp/#{name}" para evitar ejecutarse como root .omnibus-software . Por lo tanto, desea usar los que necesitará para desenchufarlo en Gemfile , o bifurcarlo, y luego hacer referencia al suyo/opt/$project/bin , deberá usar AppBundler, o deberá tener un paso de instalación posterior para crear esos estubos binstubes.ruby , también deberá anular rubygems y bundler para que coincidan con las versiones en esa versión de ruby o obtendrá fallas en los coincidencias de la versión Bundler. El comando de compilación anterior, por supuesto, construirá en su host local, así que es específico del sistema operativo y el sistema base en el que se encuentra. Pero la configuración de esqueletos de omnibus new ya configuración para usted para usted para que sea fácil de construir para una variedad de OSE, consulte el README.md en su directorio omnibus generado para obtener más detalles.
Las definiciones de software basadas en GIT pueden especificar las ramas como su default_version. En este caso, la revisión exacta de GIT a usar se determinará en el tiempo de compilación a menos que se utilice una anulación de proyecto (ver más abajo) o la versión externa de la versión. Para generar un manifiesto de la versión, use el comando omnibus manifest :
omnibus manifest PROJECT -l warn
Esto generará un manifiesto formato en forma de JSON que contiene la versión resuelta de cada definición de software.
A veces, una plataforma tiene bibliotecas que necesitan ser blancas para que la salud pueda pasar. La lista blanca que se encuentra en el código HealthCheck comprende lo mínimo requerido para las compilaciones exitosas en plataformas compatibles.
Para agregar su propia biblioteca con la lista blanca, simplemente agregue una regex a su definición de software en su proyecto Omnibus de la siguiente manera:
whitelist_file /libpcrecpp.so..+/
Por lo general, es una buena idea agregar un condicional a la lista blanca basada en la plataforma específica que lo requiere.
ADVERTENCIA: solo debe agregar bibliotecas a la lista blanca que se garantiza que estará en el sistema al que instala; Si una biblioteca proviene de un paquete no defectuoso, debe incorporarla en el paquete.
Estado: experimental
omnibus changelog generate generará un CangeLog para un proyecto Omnibus. Este comando asume actualmente:
Estos supuestos cambiarán a medida que determinemos qué funciona mejor para varios de nuestros proyectos.
Las definiciones del proyecto pueden anular las dependencias específicas del software al pasar la override para usar la versión correcta:
name "chef-full"
# <snip>
# This will override the default version of "chef"
override :chef , version : "2.1.1"
dependency "chef"¡La versión anulada debe definirse en el software asociado!
Por defecto, Omnibus registrará al nivel de warn . Puede anular esto pasando el indicador --log-level a su llamada omnibus:
$ bin/omnibus build < project > --log-level info # or "debug" Por defecto, Omnibus Caches compiló definiciones de software, por lo que las compilaciones de proyectos omnibus n+1 son mucho más rápidas. Esta funcionalidad se puede deshabilitar agregando lo siguiente a su omnibus.rb :
use_git_caching false Para obtener información sobre cómo contribuir a este proyecto, consulte 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.
