O que é uma boa abordagem de devops para um único desenvolvedor escrevendo aplicativos da web python?


8

Estou supondo que essa pergunta pareça incrivelmente trivial para alguns leitores, mas como alguém que é desenvolvedor, mas com pouca experiência em implantar aplicativos em algo que não seja um manual, acerte e espere uma maneira, espero que você entenda que é bastante assustador ver o número de diferentes abordagens e ferramentas que existem, para que eu pudesse seguir alguns conselhos para começar na direção certa.

Sou desenvolvedor, agora apenas no meu tempo livre, que é limitado. Até agora, eu trabalhei com Java, construindo webapps e fiquei razoavelmente feliz em implantar um arquivo de guerra em um ambiente Tomcat que mantém as coisas bem encapsuladas.

Agora estou trabalhando em Python e Django, mas à medida que me aproximo do ponto em que preciso implantar, desejo configurar um fluxo de trabalho de devops sólido para automatizar o máximo possível e garantir que seja possível implantar de maneira confiável, mas, considerando que meu Caso de uso seja relativamente simples, desejo evitar o aprendizado de um grande conjunto de ferramentas com excesso de engenharia para minhas necessidades e que exige um grande investimento de tempo. Prefiro usar a codificação do meu aplicativo.

Portanto, estou procurando um meio termo que permita implantar e gerenciar meus aplicativos de maneira confiável, sem investir muito tempo configurando e aprendendo um grande ecossistema de devops.

Mais alguns detalhes ...

Contexto

  1. Desenvolvo em um Mac, usando PyCharm para criar o Django 2, Python 3.
  2. Eu uso o git (mas não no github) para gerenciar a versão do software.
  3. Eu me sinto confortável com outras linguagens e linguagens de script e escrevi alguns scripts bash (provavelmente bastante amadores), embora eu não goste do bash. Eu também me envolvi com o Perl, que percebi que não é realmente um idioma para se envolver (ou seja, você precisa gastar tempo aprendendo adequadamente)
  4. Pretendo implantar em um ambiente VPS, provavelmente DigitalOcean.
  5. Meu aplicativo não é de missão crítica, mas é importante que eu saiba se o site está inoperante e, se isso acontecer, preciso recuperar de maneira confiável, seja reiniciando o aplicativo, reiniciando o servidor ou movendo-se para outro servidor ( ou outro).

Requisitos Específicos

  1. Capacidade de configurar um novo ambiente para receber o aplicativo.

    Até o momento, enquanto estou aprendendo, isso tem sido manual e, toda vez que o faço, comecei do zero com um novo Droplet. Eu gostaria que isso fosse muito mais simples (automatizado), para que, se eu tiver que configurar um novo ambiente em uma emergência, eu possa fazê-lo de maneira confiável.

  2. Capacidade de implantar o aplicativo em um ambiente de armazenamento temporário o mais idêntico possível ao vivo, idealmente como um processo automatizado acionado por um push git usando uma abordagem de integração contínua (o que nunca fiz antes).

  3. Capacidade de "pressionar o botão" quando estiver satisfeito com o aplicativo no ambiente de preparação para enviar automaticamente para um ambiente ao vivo.

  4. Maneira de monitorar o site (basta fazer uma pesquisa em uma página)

  5. Maneira de mudar o site ativo para outro servidor se eu precisar me recuperar de uma falha de aplicativo ou servidor no site ativo. Eu acho que talvez uma abordagem azul-verde funcione para mim?

O que eu tentei ou considerei?

  • Configuração manual do ambiente ao vivo com o aplicativo Django e copie manualmente uma nova base de código para ele quando houver uma alteração. Isso parece propenso a erros humanos e temo cometer um erro em uma implantação, causando uma falha irrecuperável.

  • Docker. Admito que, quando descobri sobre o Docker, parecia um sonho tornado realidade, mas depois de um pouco de experiências e pesquisas, fico assustada com o quanto preciso aprender e saber para colocar isso em funcionamento e gerenciá-lo. Pode ser que valha a pena, porque, uma vez que está funcionando, é um risco muito baixo, mas no momento parece um investimento maior do meu tempo do que eu esperava.

  • Scripts Bash. Use-os para configurar o ambiente original e para tarefas específicas, como atualizar o aplicativo. Minha preocupação com isso é que os scripts serão códigos que precisam ser testados e temo que levaria muito tempo para criar um conjunto de ferramentas confiável dessa maneira.

  • Examinei as opções da Digital Ocean para endereços IP flutuantes e a capacidade de ter dois servidores para uma abordagem "verde azul" que parece bastante sensata. Se eu seguir esse caminho, ainda preciso automatizar a implantação.

Então ... Estou procurando conselhos sobre uma abordagem de devops que encontre o equilíbrio certo entre minimizar o risco (por exemplo, o risco de interromper o aplicativo ao vivo com uma atualização ou o risco de não conseguir se recuperar de uma falha) e minimizar o tempo investimento que preciso fazer para configurar os ambientes e o fluxo de trabalho.

Respostas:


5

Não estou familiarizado com o desenvolvimento do Python nem com o DigitalOcean, portanto, apenas darei algumas dicas:

  • O objetivo é automatizar. Tudo. Como você consegue isso realmente depende de você, e a criação de suas próprias ferramentas não é exagerada, muitos fazem dessa maneira. Uma fruta concreta e bastante baixa (ish) é executar um gancho pós-recebimento do git, que implanta e reinicia seu ambiente de teste. Se você tiver isso, o resto deve ser simples.
  • "Minha preocupação é que os scripts sejam códigos que precisam ser testados" - essa preocupação é infundada. Você está testando esses scripts sempre que implantar em seu ambiente de teste. Especialmente associado a uma abordagem azul esverdeada, será bom ter scripts bash.
  • "Eu não gosto de festa." - encontre outra linguagem de script que você goste. Talvez tente Ruby? A linguagem e as bibliotecas principais são muito limpas e bem documentadas, e eu diria, fáceis de aprender. Ou, apenas por diversão, Go (lang), que parece ser adequado para devops tarefas de ferramentas. E, finalmente, como você parece gostar do Python, certamente também pode executar tarefas de instalação. A partir deles, o Go tem o benefício de criar binários autônomos e não precisa de um ambiente complexo instalado primeiro, portanto, a inicialização pode ser mais fácil.
  • "um ambiente de teste o mais idêntico ao vivo possível" - se você tiver um script que gera um ambiente do zero, ou seja, a partir de uma imagem base mais ou menos vazia, seus ambientes serão idênticos, exceto os deltas codificados em seu script. Esse é o objetivo de tudo isso.
  • "Maneira de mudar o site ativo para outro servidor" - a única coisa a considerar é o que acontece com seus dados persistentes. Ou seja, você desejará fazer isso para poder vincular seus aplicativos a diferentes volumes / lojas persistentes em tempo real, para poder alternar entre si.
  • "Docker - assustado" - para ser sincero, não deve ser tão ruim assim. Se você sabe como construir um ambiente do zero com ferramentas de linha de comando (sem ferramentas da GUI), colocá-las em um Dockerfile deve ser bastante fácil. Os detalhes preocupantes aparecem quando é hora de ajustar (ou seja, reduzir o tamanho da imagem), mas, além disso, não deve ser muito ruim. Primeiro faça com que funcione de alguma forma e depois descubra como torná-lo bonito. O bom é que o conhecimento que você obtém será transferido para muitos outros ambientes.

Boa sorte!


3

Obrigado pela ótima pergunta. Nada é realmente trivial na primeira vez que você faz isso e todos nós éramos novos em algo uma vez.

Minha primeira recomendação é revisitar o docker. Experimente alguns guias e tutoriais diferentes. É realmente simples. Você tem um arquivo docker que é "construído", literalmente apenas os comandos que você deseja que sejam executados no "contêiner" ou na "imagem". Você envia essa imagem para um registro que pode ser público ou privado. Você então executa essa imagem em uma máquina host. O Docker é realmente importante com o node.js e o python, onde você tem muitas dependências e às vezes pode ser difícil gerenciá-las. Se você estiver usando o pip, e deve estar, pode gerar um requirements.txtarquivo para alimentar o seu contêiner do docker.

Agora você disse que está usando o git, então eu usaria ganchos locais do git. Você pode usá-los para criar o contêiner de docker, executar testes automatizados e implantar seu contêiner. Você pode procurar vários guias e tutoriais diferentes sobre esse assunto.

Para gerenciar sua infraestrutura, você usaria o Terraform. O Terraform é ótimo porque você pode criar um ambiente sob demanda e excluí-lo quando terminar. Minha recomendação seria começar de maneira simples e, depois de dominar o docker e o terraform, você pode tentar implantações em azul / verde.

Agora, se você estiver usando o Gitlab ou quiser mudar, ele também oferece um serviço gratuito de ci / cd. Isso inclui muitos recursos interessantes e é realmente fácil de usar. Eu o uso pessoalmente para todos os meus aplicativos. Você pode ignorar completamente os ganchos locais do git e testar no pipeline do gitlab ou mantê-los para testar cada confirmação localmente e usar o gitlab para criar e implantar.

Espero que isso tenha sido útil.


1
Com o Docker, o que achei um pouco assustador foi o princípio de ter componentes em diferentes contêineres. Então, um para o aplicativo, outro para o Gunicorn, outro para o Nginx etc. Você precisa colocar configurações adicionais para que eles conversem entre si. Parece anular o objetivo de ter um único contêiner encapsulado que é transferível para qualquer ambiente. No entanto, como esta resposta e a @ Anoe recomendaram dar outra olhada, eu farei.
Auspice

1
@Auspice Essa é mais uma abordagem de "micro serviços". Embora seja uma prática recomendada que um contêiner de docker tenha apenas um único processo, geralmente não é o que vejo. Marque "O caminho do Docker?" aqui github.com/just-containers/s6-overlay . Eu pessoalmente mostraria minha infra usando o Ansible. Eu usaria ansible para chamar Terraform para criá-lo. Em seguida, usaria o ansible para atualizar meus servidores, instalar o docker, instalar o nginx e iniciar os aplicativos do docker como serviços. Eu teria ansible configurar o nginx para proxy para os contêineres onde estão o aplicativo e o gunicorn.
Levi

0

As respostas postadas foram muito úteis para que eu pudesse repensar meu problema e várias abordagens. Ainda não implementei uma solução, mas decidi por uma abordagem, por isso estou documentando e selecionando-a como resposta. Em resumo, é o seguinte:

Minha abordagem escolhida

  • Para o ambiente ao vivo, usarei duas máquinas virtuais (provavelmente usando gotículas DigitalOcean) executando o Ubuntu e configuradas exatamente da mesma forma.
  • Empregarei uma abordagem azul esverdeado usando o recurso de IP flutuante no DO para manter meus dois servidores idênticos aos do Live e Pre-Prod / Backup.
  • Vou criar uma VM (provavelmente usando o VirtualBox) em minha configuração de desenvolvimento para uso como um ambiente de preparação. Esta VM será configurada exatamente como meus dois servidores ativos.
  • Escreverei um único script comum em Python para configurar um ambiente do zero e usarei isso para configurar meu ambiente de teste e meu par de produção / pré-produção.
  • Empregarei ganchos do git para acionar atualizações nos ambientes (provavelmente acionadas manualmente).

Considerações que conduziram essa abordagem

  • Docker: Eu decidi contra. Embora eu leve a sério as respostas (obrigado @Levi e @Dan) que dizem que eu deveria voltar a visitar e que não deveria ser tão ruim, tive muitas experiências no passado ao embarcar em algo novo e perceber que caí por uma toca de coelho que consome tempo e leva uma idade para continuar. Eu acho que seria diferente se eu estivesse trabalhando com outra pessoa, mas como alguém trabalhando completamente sozinho a cada minuto é precioso.

  • Máquinas virtuais: eu realmente não tinha pensado nisso até começar a trabalhar com alguns dos tutoriais do Docker que usam VMs para demonstrar a funcionalidade Swarm. A idéia de poder criar um ambiente totalmente novo, do qual tenho controle total, é muito atraente.

  • Criação de scripts: solicitado pela resposta útil de @ AnoE Eu fiz um pouco mais de pesquisa e parece que o Python é reconhecido como uma opção viável para criação de scripts. para aprender algo novo para o meu script, será um conhecimento que eu possa usar ao escrever meu aplicativo)

Eu atualizarei uma vez que tenha feito algum progresso nisso e, se der terrivelmente errado, reconhecerei que talvez tenha feito a escolha errada!).

Atualização em 20 de outubro de 2018.

Decidi escrever um script Python, mas isso geralmente envolvia invocar um comando bash do Python e, em seguida, obter a resposta novamente. Achei isso bastante adicionado ao tempo de desenvolvimento. Depois de algumas semanas de progresso lento, procurei em outro lugar. Admito que posso ter me aproximado errado, mas precisava de algo que fosse mais rápido.

Acabei optando pelo Vagrant / Ansible / VirtualBox e, depois de mais meses do que eu gostaria de admitir, conseguiu algo que funcionou bem, mas depois de muito trabalho aprendendo algumas novas habilidades (o Vagrant e o Ansible eram completamente novos para mim). Em seguida, apliquei o script Ansible para provisionar um DigitalOcean Droplet e constatei que isso funcionava muito bem. Tornei-me fã do Ansible, mas, embora concorde (com os revisores) que é relativamente fácil de usar, ainda é um novo paradigma e uma curva de aprendizado bastante acentuada.

No momento da redação deste artigo, provisionei duas gotículas separadas no DigitalOcean em uma configuração azul esverdeada, usando os endereços IP flutuantes do DO para alternar entre as duas, e em cada um o aplicativo está dentro de uma cópia de trabalho do git, então só preciso atualizar o Mestre para atualizar um ambiente.

Estou com um problema para fazer com que os IPs flutuantes funcionem como eu esperava, mas espero resolver isso em breve e depois terei um ambiente de DevOps funcional.

A grande vantagem dessa abordagem é que, da maneira como o Ansible funciona, depois de ter algo funcionando, é relativamente fácil fazê-lo funcionar em um ambiente diferente e isso pode não ser tão fácil de obter com um script python (ou pelo menos você precisa criar isso é trabalho extra).

Eu acho que a grande lição é que as coisas demoram mais do que eu esperava e aprender uma nova tecnologia sempre traz incógnitas desconhecidas. Isso não deveria ser uma surpresa para mim - mas sempre é e, como desenvolvedor solitário, isso acontece muito comigo.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.