Atualizações do sistema para muitos servidores

11

Temos muitos servidores e ainda queremos atualizá-los todos. A maneira real é que qualquer um dos sysadmins vai de um servidor para outro e faz um aptitude update && aptitude upgrade - ainda não é legal.

Estou procurando agora uma solução ainda melhor e muito inteligente. O fantoche pode fazer esse trabalho? Como você faz isso?

    
por Dennis Wisnia 03.01.2012 / 08:11

11 respostas

10

Você pode usar o tipo exec , como:

exec { "upgrade_packages":
    command => "apt-get upgrade -q=2",
    path    => "/usr/local/bin/:/bin/:/usr/bin/",
    # path  => [ "/usr/local/bin/", "/bin/" ],  # alternative syntax
}

Para ser honesto, eu não tentei por mim mesmo, mas acho que você só precisa criar um novo módulo que inclua essa definição de exec.

O comando apt-get upgrade é interativo. Para fazê-lo funcionar silenciosamente, você pode adicionar a opção -q=2 como mostrado acima.

    
por 03.01.2012 / 08:58
7

se todos os seus hosts forem debian, você pode tentar o pacote de upgrades não supervisionados.

link

Aqui, usamos o fantoche para gerenciar nossas máquinas virtuais do Debian, com o fantoche podemos habilitar e gerenciar configurações de atualização não-animada em todos os servidores.

Recentemente, nossa equipe está testando a ferramenta coletiva para executar comandos em todos os servidores, mas é necessário usar habilidades de rubi coletivas.

[s] Guto

    
por 03.01.2012 / 16:42
5

Eu recomendaria ir para Puppet, facter e mCollective.

mCollective é um framework muito legal no qual você pode executar comandos sobre uma série de hosts (em paralelos) usando o facter como filter.

Adicione a isso um proxy / cache local e você estará bem definido para o gerenciamento de servidores.

    
por 03.01.2012 / 13:40
3

Use uma ferramenta criada para executar um único comando em vários servidores. E com isso não quero dizer que ter um terminal kazillion aberto com Terminator ou ClusterSSH, mas ter um único terminal para um servidor de gerenciamento executando uma ferramenta adequada para o trabalho.

Eu recomendaria func, Salt ou mCollective neste contexto. Se você já tem o Puppet, vá para o mCollective (ele se integra muito bem no Puppet). Se você não tem, e você tem um antigo Python em suas máquinas, você pode desfrutar de func. Se você Python em novo, tente Sal. Todas essas ferramentas executam o comando especificado na linha de comando de forma assíncrona, o que é muito mais divertido do que um loop ssh sequencial ou até mesmo fazendo os mesmos comandos do aptitude em muitas janelas do Exterminador para muitos servidores.

Você definitivamente adorará Sal .

    
por 03.01.2012 / 11:29
2

Então, acho que há muitas coisas que contribuem para uma boa solução:

  • Largura de banda
  • Facilidade de administração
  • Registro detalhado no caso de algo estragar.

Largura de banda : Basicamente, duas alternativas para economizar largura de banda me vêm à mente:

  • Configurando um espelho Debian e configurando todos os seus clientes para usar esse espelho, veja link para mais detalhes. (Eu recomendaria isso)
  • Configurando um proxy (apt-cacher, apt-proxy ou Squid) e aumentando o cache para que todos os seus clientes possam lucrar com esse cache

Administração : eu configuraria um shell paralelo como PDSH , PSSH , Paralelo GNU e emita o comando em todos os clientes, se eu testei o comando anteriormente em uma máquina de exemplo. Então não é muito provável que isso possa falhar em todos os outros. Alternativamente, você pode considerar um cron job em todos os clientes, mas pode falhar automaticamente, então prefiro a primeira solução.

Se você se preocupa com a simultaneidade de upgrades, pode agendar seus comandos com at

Logging : Como com shells paralelos, você tem a possibilidade de redirecionar a saída. Eu combinaria stderr e stdout e gravaria em um arquivo de log.

    
por 03.01.2012 / 10:17
1

Meu próprio ssh wrapper paralelo: classh é uma alternativa para as várias ferramentas paralelas e de cluster ssh disponíveis.

Você pode gostar mais ou odiar. Há apenas três razões pelas quais estou mencionando aqui:

  • É extremamente simples de instalar e usar: um único arquivo .py sem dependências externas além das bibliotecas padrão do Python 2.5.
  • É extremamente confiável dentro de seus limites. Eu uso todos os dias úteis, quase 100 vezes por dia e geralmente em coleções de centenas a alguns milhares de alvos por comando. (Eu testei em listas de destino de mais de 25 mil servidores por vez). Nunca falhou em executar, falhou em concluir ou me deu qualquer comportamento indeterminado. (As únicas limitações relacionadas àquelas do método subprocess.communicate() do Python - portanto, você só pode capturar cerca de 64K de stdout e, separadamente, até 64K de stderr, por exemplo; também qualquer processo remoto que tente ler de seu stdin irá simplesmente parar até que o sub-espaço ssh local seja eliminado, automaticamente pelo tratamento de timeout do classh )
  • É extremamente simples escrever um script personalizado, em Python, para usar o classh.py como um módulo. Então é muito fácil escrever algo como:

    
        !#/bin/env python
        import classh
        job = classh.SSHJobMan(cmd, targets)
        job.start()
        while not job.done():
            completed = job.poll()
            for i in completed:
                # do something with the classh.JobRecord object referenced by i
        # done
    
    # You can optionally do post-processing on the dictionary of JobRecords here
    #  keyed off the target strings (hostnames)    
    </code></pre>
    

Isso é tudo que existe para isso. Por exemplo, no loop concluído aninhado, você pode reunir uma lista de todos aqueles que retornaram algum status de saída específico ou verificar mensagens de erro específicas e configurar trabalhos de acompanhamento para lidar com eles. (Os trabalhos serão executados simultaneamente, padrão de 100 trabalhos a qualquer momento, até que cada um esteja concluído; portanto, um comando simples em algumas centenas de hosts geralmente é concluído em poucos segundos e um script de shell muito complexo em uma única cadeia longa de comando. digamos cinquenta linhas ou mais ... pode completar mais de alguns milhares de hosts em cerca de 10 minutos ... cerca de 10 K hosts por hora no meu ambiente, com muitos deles localizados intercontinentalmente).

Então, isso pode ser algo que você pode usar como uma medida ad hoc até ter sua configuração de marionetes implementada e bem testada ... e também é bastante útil para realizar pequenas pesquisas ad hoc de seus hosts para ver quais estão se desviando seus padrões de várias maneiras.

    
por 03.01.2012 / 12:34
1

A resposta usando exec é bastante útil.

No entanto, de acordo com o manual do apt-get, não é uma boa idéia usar -q = 2 desta forma (embora eu tenha usado por anos sem problemas)

-q, --quiet
       Quiet; produces output suitable for logging, omitting progress indicators. More q's will produce more quiet up to a maximum of 2. You can also use -q=# to set the
       quiet level, overriding the configuration file. Note that quiet level 2 implies -y, you should never use -qq without a no-action modifier such as -d, --print-uris or
       -s as APT may decided to do something you did not expect. Configuration Item: quiet.

Eu mesmo usei um script por anos, executando o apt-get da seguinte maneira:

ssh example.org "apt-get update && apt-get -y upgrade && apt-get -y dist-upgrade && apt-get clean"

Coisas como fantoches e outras ferramentas que as pessoas mencionaram certamente podem funcionar, mas parece que é um exagero para o que basicamente é apenas imitar alguns comandos digitados por um ser humano. Eu acredito em usar a ferramenta mais simples para um trabalho específico, neste caso, um script bash é tão simples quanto possível sem perder a funcionalidade.

    
por 06.01.2012 / 22:10
1

Durante anos, atualizei e instalei pacotes com sucesso usando o apt-dater . É uma ferramenta leve e eficaz para gerenciamento remoto de pacotes. Usa screen , sudo e ssh .
Para o gerenciamento de pacotes apt-dater pode ser uma solução mais fácil do que ferramentas de gerenciamento de configuração.
apt-dater é útil para o gerenciamento centralizado de pacotes em diferentes versões do GNU / Linux, como Debian e CentOS.

    
por 24.07.2013 / 03:09
1

você pode usar Tecido . O Fabric é uma biblioteca e ferramenta de linha de comando do Python (2.5-2.7) para simplificar o uso de SSH para implementação de aplicativos ou tarefas de administração de sistemas.

    
por 27.06.2014 / 11:54
0

use o webmin , e use seu recurso de cluster webmin, no qual você pode adicionar todos os sistemas a um console do webmin e emiti-los a qualquer comando ou controle todos eles de um único local.

Ou

Usar o cluster ssh

Ou

PSSH

    
por 03.01.2012 / 08:41
0

Outra solução se todos os seus hosts estiverem rodando Debian (ou derivados) é usar o pacote cron-apt . Mas, conforme sugerido pela documentação, um pouco de cuidado deve ser tomado.

Atualmente, estou usando o cron-apt em uma dezena de servidores para executar todas as atualizações de segurança automaticamente e sem supervisão. Para evitar atualizações indesejadas, eu só uso o cron-apt em servidores que executam a distribuição estável do Debian e asseguro-me de configurar meus apt sources então use o nome da distribuição wheezy , e não seu alias (stable ).

A configuração específica do cron-apt que eu uso é resumida em um arquivo de ação: /etc/cron-apt/action.d/5-install

dist-upgrade -y -o APT::Get::Show-Upgraded=true -o Dir::Etc::SourceList=/etc/apt/sources.list.d/security.list -o Dir::Etc::SourceParts="/dev/null"

Qualquer outra atualização é feita manualmente, usando a tela ou o que for mais apropriado, pois pode exigir intervenção manual durante a atualização.

    
por 28.06.2014 / 14:59