Automação da configuração do servidor: Ubuntu no Windows Azure (+ WordPress, Nginx, Git)

Question

Gostaríamos de algumas ideias sobre como configurar automaticamente as máquinas virtuais do Ubuntu como servidores de teste para nosso aplicativo, testar o código de preparação e depois implantar scripts no servidor de produção (em vez de instalar tudo no servidor de teste por meio de ssh, copiando arquivos, configurações de edição manual, etc.)

Podemos mudar para a AWS, se necessário, mas estamos bem no Azure por enquanto --- basicamente obtemos uma VM do Ubuntu com acesso SSH no Azure, por isso não deve ser diferente de outras maneiras de configurar o linux. servidores baseados eu imagino

O que queremos que um script faça é basicamente:

• Entre "na" nova máquina virtual via SSH
• Configuração nginx, MariaDB, php, outras instalações do apt-get
• Implante uma cópia do nosso código wordpress de um repositório Git
• Importe um banco de dados de preparo de amostra para o MariaDB com informações de configuração do wordpress e outras informações
• Use a API do cloudflare para configurar um nome de host DNS para o servidor (opcional, pode fazer isso manualmente, se necessário)
• Deixe a pessoa testando o novo código cutucar

Então, se funcionar bem, queremos automatizar o envio do novo código no Git para o nosso servidor de produção, sem editar manualmente os arquivos de configuração do wordpress e assim por diante. Mas isso é um pouco separado da questão de configurar o ambiente de teste por meio de um script

As ferramentas que encontrei até agora são estas (não posso fornecer links por causa de baixa reputação)

• Chef
• Fantoche
• Vagrant
• Pilha de sal
• Ansível
• Juju

Antes de mergulhar direto neles, eu queria saber se alguém tem uma visão de 10.000 pés do que é aplicável às nossas necessidades.

    

Answer 1

O que você realmente procura são soluções para dois problemas diferentes (mas intimamente relacionados) que se sobrepõem:

1. Gerenciamento de configurações
2. Automação de implantação

Há alguma sobreposição entre os dois e, à medida que você começa, provavelmente será um pouco confuso quais ferramentas usar para quais partes de sua infraestrutura. Aqui estão algumas diretrizes gerais para você começar:

As ferramentas de gerenciamento de configuração geralmente seguem um modelo orientado a recursos , idempotent . Ou seja, você modela seu sistema como um conjunto de recursos que tem estado e executa sua ferramenta de gerenciamento de configuração continuamente para ver se algo parece diferente da sua especificação. Se o recurso não estiver nesse estado, você terá alguma lógica específica do tipo para colocar o recurso nesse estado. Um pacote ou uma conta de usuário é um recurso simples e óbvio, mas você também pode ter modelos ElasticSearch, entradas em seu banco de dados SELinux ou hosts Nagios que também podem ser declarados como recursos em seu sistema de gerenciamento de configurações.

Como um exemplo rápido, um pacote pode ser instalado ou não instalado , e pode ter uma versão anexada. Uma ferramenta de gerenciamento de configuração será capaz de pegar uma especificação de configuração que diz que o pacote X deve ser instalado , ver que não está instalado atualmente, e tomar as medidas corretas para trazê-lo de não instalado para o estado instalado (obviamente, instalando-o).

Idempotence significa que você pode aplicar a mesma configuração dez, cem ou mil vezes e obter exatamente o mesmo resultado - apenas as coisas que precisam ser alteradas são realmente alteradas. Isso está em contraste com um script que pode, digamos, anexar uma linha a um arquivo de configuração cem vezes (o que significa que você acaba com a mesma linha nesse arquivo cem vezes).

As desvantagens de um sistema de gerenciamento de configuração usando esse modelo são que as associações entre seus recursos são bastante frouxas, elas não são mapeadas para tarefas de longa execução, como importações de banco de dados ou migrações de esquema, e geralmente não são fornecidas uma tonelada de controle sobre exatamente em que ordem as coisas são aplicadas em vários sistemas em uma pilha.

Puppet e Chef são exemplos de sistemas de gerenciamento de configuração.

As ferramentas

Deployment automation são para executar tarefas ad-hoc . Em outras palavras, você os executa explicitamente quando precisa fazer alguma coisa. (Ok, às vezes você os executa implicitamente a partir de um gatilho, como de um sistema de integração contínua.) Eles geralmente orquestram vários sistemas de uma maneira previsível; por exemplo, você pode querer apenas que um de seus servidores da web execute uma migração de banco de dados durante uma atualização, e talvez você queira fazer a atualização do servidor de aplicativos apenas se a migração do banco de dados for bem-sucedida e talvez queira que os servidores de aplicativos reiniciem três vezes tempo para que você não reduza toda a sua aplicação durante a atualização. O mais importante é que você só quer que esse processo inicie exatamente quando você diz para .

Capistrano e Fabric são exemplos populares de ferramentas de automação de implantação. Para servidores únicos, você pode facilmente usar coisas como Makefiles em todo o seu aplicativo.

Em seu caso particular, você provavelmente quer um sistema de gerenciamento de configuração que lide com coisas como a instalação do seu sistema de banco de dados e PHP, e a configuração do seu servidor web. Por outro lado, você provavelmente quer uma ferramenta de implantação para lidar com a criação de seus bancos de dados e a população de seus dados de teste neles. O download do código do aplicativo do Git pode ser facilmente modelado por um gerenciamento de configuração ou por uma ferramenta de automação de implementação, dependendo de qual se adapte melhor às suas necessidades. E independentemente do método escolhido, as pessoas têm opiniões divergentes sobre como os arquivos de configuração do aplicativo devem entrar no servidor.

A coisa mais importante quando você está trabalhando com ferramentas como essas é que elas são um desperdício completo se você não as estiver usando corretamente. Em outras palavras, se você estiver usando um método sofisticado de implantação automatizada para colocar seu aplicativo em teste, e seu servidor de produção não se parecer exatamente com o servidor de teste sofisticado, você terá perdido muito esforço por quase sem ganho. Faça as coisas direito e elas servirão muito bem a você.

    

Answer 2

Eu sou mais do tipo RH (e eu usaria o kickstart para fazer o básico + fantoche para fazer o resto), mas, de qualquer maneira, tente o fantoche. Deve ser fácil começar já que, há algum tempo, a Wikimedia publicou o GIT com todos os seus arquivos de configuração de fantoches:

link

    

Answer 3

Eu sei que esta resposta pode parecer estranha ... mas considere o uso do Hudson, você pode fazer o que você quiser, apenas por alguns ajustes ... e escrever os scripts ..

    

Answer 4

O que você está vendo são duas coisas -

• gerenciamento de configurações
• automação de implantação

Sugiro usar o Chef e você pode usar o bootstrap do chef que é agnóstico do SO.

A primeira parte que você deseja configurar é apenas mariadb, nginx, php e outros pacotes, o que é simples e simples com o chef.

Segunda parte é a configuração inicial - como importar banco de dados, configurar dns, permitir que o usuário faça login para configurar ssh keys, você ainda pode usar o chef e fazer uma verificação para sabermos que esses scripts precisam ser executados pela primeira vez, como primeiro arrancar em muitos sistemas

Para a terceira parte, que é a implantação contínua, você precisa descobrir os gatilhos (como cada git checkin deve acionar uma atualização do git na máquina local, o que pode ser feito usando a tarefa cron simples agendada que corresponde ao número da cabeça remota número da cabeça, se eles estão em desacordo, então é só uma questão de puxar o código para baixo)

Como você está usando o php, você não tem que reiniciar o servidor ou coisas do tipo, então é bom fazer um git pull.

então o que jgoldschrafe disse faz sentido; Eu apenas faria isso com um monte de scripts de chefs rodando no site do cliente. Se você tiver vários nós, eu também configuraria o servidor do chef e os executaria como cliente do chef.

    

Answer 5

Eu usaria o Ansible - é muito mais simples começar com o Ansible do que o Chef, o Puppet ou o Saltstack, que fazem um trabalho semelhante mas tem uma curva de aprendizado muito mais acentuada (apenas instalar o Puppet demora bastante, devido à necessidade de servidor, enquanto o Ansible é apenas um único comando de instalação e não requer servidor.

Ansible funciona bem para configurar VMs Linux em execução no Azure e, se desejar, também pode criar recursos do Azure, como VMs, interfaces de rede e grupos de segurança de rede. Se preferir usar a CLI do Azure, basta incorporar os comandos da CLI no Ansible usando o módulo shell , desde que sejam idempotentes (tenham o mesmo efeito, mesmo que sejam executados novamente).

Dê uma olhada nos papéis Ansible (módulos de script reutilizáveis de terceiros) para seus componentes - existem funções para WordPress, MariaDB / MySQL e CloudFlare. Experimente os papéis de Jeff Geerling primeiro, eles tendem a funcionar bem se eles cobrem o que você precisa.

Depois, você pode escrever um código específico sobre essas funções para fazer o que quiser.

Ansible também funciona bem para automação de implementação, para substituir Fabric Capistrano (procure por Ansistrano se você gostar do modelo Capistrano).