omnibus
v3.2.0
OmnibusProjeto Umbrella : Chef Foundation
Estado do projeto : ativo
Problemas Tempo de resposta Máximo : 14 dias
Puxe o tempo de resposta do pedido máximo : 14 dias
Crie facilmente instaladores de pilha completa para o seu projeto em uma variedade de plataformas.
Seth Chisamore e Christopher Maier, do Chef, deram uma palestra introdutória sobre Omnibus no Chefconf 2013, intitulada Eat a tigela inteira: construindo um instalador de pilha completa com Omnibus :
Este projeto é gerenciado pela equipe de engenharia de liberação do chef. Para obter mais informações sobre o processo de contribuição, triagem e liberação da equipe de engenharia de liberação, consulte o Guia de Gerenciamento de OSS de engenharia de liberação do chef.
Omnibus foi projetado para executar com um conjunto mínimo de pré -requisitos. Você precisará do seguinte:
O Omnibus fornece um DSL para definir projetos de omnibus para o seu software, bem como uma ferramenta de linha de comando para gerar artefatos do instalador a partir dessa definição.
Para começar, instale o Omnibus localmente em sua estação de trabalho.
$ gem install omnibusAgora você pode criar um projeto Omnibus no seu diretório atual usando o recurso Gerador do Projeto.
$ omnibus new $MY_PROJECT_NAME Isso gerará um esqueleto de projeto completo no diretório omnibus-$MY_PROJECT_NAME
Por padrão, isso fará um diretório chamado omnibus-$MY_PROJECT_NAME assumindo que você está mantendo sua configuração omnibus separada do repo. No entanto, mantê -lo em seu repositório é uma prática comum; portanto, sinta renomear esse diretório para omnibus e colocá -lo no nível superior do repositório de seus projetos.
$ cd omnibus- $MY_PROJECT_NAME
$ bundle install --binstubsMais detalhes podem ser encontrados no arquivo readme do projeto gerado.
Omnibus determina a plataforma para a qual criar um instalador com base na plataforma em que está em execução atualmente . Ou seja, você só pode gerar um arquivo .deb em um sistema baseado em Debian. Para aliviar essa ressalva, o projeto gerado inclui uma configuração de cozinha de teste adequada para gerar uma série de projetos Omnibus.
Embora o projeto de modelo seja construído, ele não fará nada emocionante. Para isso, você precisa usar o Omnibus DSL para definir as especificidades do seu aplicativo.
Se presente, o Omnibus usará um arquivo de configuração de nível superior chamado omnibus.rb na raiz do seu repositório. Este arquivo é carregado no tempo de execução e inclui vários tunables de configuração. Aqui está um exemplo:
# 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 mais informações, consulte a documentação Config .
Você pode dizer ao Omnibus para carregar um arquivo de configuração diferente, passando a opção --config para qualquer comando:
$ bin/omnibus --config /path/to/config.rb Por fim, você pode substituir uma opção de configuração específica na linha de comando usando o sinalizador --override . Isso tem precedência final sobre quaisquer valores de arquivo de configuração:
$ bin/omnibus --override use_git_caching:falseUm arquivo DSL do Projeto define seu aplicativo real; É isso que você está criando um instalador de pilha completa em primeiro lugar. Ele fornece um meio de definir as dependências do projeto (novamente, conforme especificado nos arquivos de definição de DSL de software), bem como maneiras de definir os metadados do pacote do instalador.
Todas as definições do projeto devem estar no diretório config/projects do seu repositório 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"Alguns métodos DSL disponíveis incluem:
| Método DSL | Descrição |
|---|---|
name | O nome do projeto |
install_dir | O local de instalação desejado do pacote |
build_version | A versão do pacote |
build_iteration | O número da iteração do pacote |
dependency | Um componente definido por software omnibus para incluir neste pacote |
package | Invoque um DSL específico do Packager |
compress | Invoque um DSL específico do compressor |
Por padrão, um registro de data e hora é anexado ao Build_Version. Você pode desativar esse comportamento configurando append_timestamp como false em seu omnibus.rb ou usando --override append_timestamp:false na linha de comando.
Para mais informações, consulte a documentação Project .
Os arquivos de "software" do Omnibus definem componentes de software individuais que são feitos para criar seu pacote geral. Eles são os blocos de construção do seu aplicativo. O software DSL fornece uma maneira de definir onde recuperar as fontes de software, como construí -las e quais dependências elas têm. Essas dependências também são definidas em seus próprios arquivos DSL de software, formando a base para uma ordem de compilação com reconhecimento de dependência.
Todas as definições de software devem ir no diretório config/software do seu repositório de projeto Omnibus.
Aqui está um exemplo:
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"
endAlguns dos métodos DSL disponíveis incluem:
| Método DSL | Descrição |
|---|---|
name | O nome do componente de software (isso deve vir primeiro) |
default_version | A versão do componente de software |
source | Instruções para a localização da fonte |
dependency | Um componente definido por software omnibus que este software depende |
relative_path | O caminho relativo do tarball extraído |
build | As instruções de construção |
Para mais métodos DSL, consulte a documentação Software .
Além disso, existem vários métodos DSL disponíveis dentro do bloco build :
| Método DSL | Descrição |
|---|---|
command | Executar um único comando de shell |
make | Executar make (com ou sem args), usando o gmake quando apropriado |
patch | Aplique um patch do disco |
workers | O número máximo de construtores |
windows_safe_path | Formate o caminho para ser seguro para se deslocar nas janelas |
go | Execute o código como o Incordded Go |
ruby | Executar o código como o rubi incorporado |
gem | Executar o código como os rubygems incorporados |
bundle | Execute o código como o empurrador incorporado |
rake | Executar o código como a gema de ancinho incorporada |
block | Execute o bloco Ruby no momento da construção |
erb | Renderizar o modelo ERB fornecido |
mkdir | Crie o diretório fornecido |
touch | Crie o arquivo vazio dado |
delete | Remova o arquivo ou diretório fornecido |
strip | Tira símbolos de binários em um determinado arquivo ou diretório |
copy | Copie A a B |
move | Mova A para B |
link | Link A a B |
sync | Copie todos os arquivos de A a B, removendo quaisquer arquivos da união |
Para mais métodos DSL, consulte a documentação Builder .
Você pode apoiar a criação de várias versões do mesmo software no mesmo arquivo de definição de software usando o método version e fornecendo um bloco:
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"
endComo as definições de software são simplesmente o código Ruby, você pode executar condicionalmente qualquer coisa, envolvendo -o com rubi puro que testa o número da versão.
A maneira mais fácil de compartilhar o software em toda a organização é via Bundler e Rubygems. Para um exemplo de repositório de software, consulte o Omnibus-Software do chef. Para mais informações, consulte a documentação do Rubygems.
Recomenda -se que você use o Bundler para abaixar essas jóias (como Bundler também permite puxar o software diretamente do GitHub):
gem 'my-company-omnibus-software'
gem 'omnibus-software' , github : 'my-company/omnibus-software' Em seguida, adicione o nome do software à lista de software_gems em sua configuração omnibus:
software_gems %w( my-company-omnibus-software omnibus-software )Você também pode especificar caminhos locais no disco (mas estar avisado que isso pode dificultar o compartilhamento do projeto entre as equipes):
local_software_dirs %w( /path/to/software /other/path/to/software ) Para todos esses caminhos, o pedido é importante , por isso é possível depender da versão local do software, mantendo um repositório de software remoto. Dado o exemplo acima, o Omnibus procurará uma definição de software chamada foo nesta ordem:
$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
A primeira instância do foo.rb encontrada será usada. Observe que as definições locais de sofra de software têm precedência!
Depois de criar seu pacote e definições de software com o qual você pode construir:
./bin/omnibus build $MY_PACKAGE_NAMENo entanto, existem várias advertências a serem cientes:
base_dir no omnibus.rb , ou, no mínimo, altere cache_dir e build_dir , caso contrário, tentará usar /var/cache/omnibus e /opt/$MY_PROJECT_NAME , requer root.config/projects/$MY_PROJECT_NAME.rb . Você pode consultar os arquivos .rb do software presentes na pasta config/software .install_dir especificado no arquivo do projeto normalmente requer privilégio root no horário de construção. Altere outro local como "/tmp/#{name}" para evitar a execução como root .omnibus-software . Então você deseja usar aqueles que precisará para descomentá -lo no Gemfile ou bifurcá -lo e depois referenciar o seu próprio/opt/$project/bin , você precisará usar o Appbundler ou precisará ter uma etapa de instalação para criar esses bancos.ruby , também precisará substituir rubygems e bundler para corresponder às versões nessa versão do ruby ou terá falhas nas incompatibilidades da versão do Bundler. É claro que o comando Build acima se baseará em seu host local, sendo específico para o sistema operacional e o sistema de base em que você está. Mas a configuração do esqueleto da omnibus new já configurada cozinha para você, para que seja fácil de construir para uma variedade de sistemas operacionais, consulte o README.md no seu diretório Omnibus gerado para obter detalhes.
As definições de software baseadas em Git podem especificar ramificações como sua default_version. Nesse caso, a revisão exata do Git a ser usada será determinada no momento da construção, a menos que uma substituição do projeto (veja abaixo) ou o manifesto da versão externa seja usado. Para gerar um manifesto de versão, use o comando omnibus manifest :
omnibus manifest PROJECT -l warn
Isso produzirá um manifesto formatado em JSON, contendo a versão resolvida de todas as definições de software.
Às vezes, uma plataforma possui bibliotecas que precisam estar em permissões para que a verificação de saúde possa passar. A lista de permissões encontrada no Código HealthCheck compreende o mínimo necessário para construções bem -sucedidas em plataformas suportadas.
Para adicionar sua própria biblioteca de permissões, basta adicionar uma regex à sua definição de software em seu projeto Omnibus da seguinte forma:
whitelist_file /libpcrecpp.so..+/
Normalmente, é uma boa idéia adicionar uma lista de permissões com base na plataforma específica que a exige.
Aviso: você deve adicionar apenas bibliotecas à lista de permissões que garantem estar no sistema para o qual você instala; Se uma biblioteca vier de um pacote que não seja de defesa, você deverá criá-lo no pacote.
Status: Experimental
omnibus changelog generate gerará um Changelog para um projeto Omnibus. Este comando atualmente assume:
Essas suposições mudarão à medida que determinarmos o que funciona melhor para vários de nossos projetos.
As definições do projeto podem substituir dependências específicas de software, passando override para usar a versão correta:
name "chef-full"
# <snip>
# This will override the default version of "chef"
override :chef , version : "2.1.1"
dependency "chef"A versão substituída deve ser definida no software associado!
Por padrão, o Omnibus registrará no nível de warn . Você pode substituir isso passando a bandeira --log-level para sua chamada omnibus:
$ bin/omnibus build < project > --log-level info # or "debug" Por padrão, as definições de software compiladas de caches omnibus, portanto, as compilações do projeto omnibus n+1 são muito mais rápidas. Essa funcionalidade pode ser desativada adicionando o seguinte ao seu omnibus.rb :
use_git_caching false Para obter informações sobre como contribuir com este projeto, 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.
