Olá Habr! Meu nome é Artyom Zheltak , sou chefe de equipe e também professor do curso "Golang Developer" na OTUS. Antecipando o início de um novo fluxo do curso , quero compartilhar meu artigo com você.
Acredito que Golang é ótimo, mas ainda existem muitos projetos php e outros trabalhando em VPS, VDS no mundo. Você pode colocar o docker lá, mas isso (de acordo com o autor) é uma re-complicação da tarefa. Você pode compilar um arquivo e fazer o upload via FTP - é inseguro e não é feng shui, o SFTP é mais seguro, mas não o feng shui novamente. Então vamos automatizar esse processo através do
CircleCI . Escreveremos o arquivo de configuração para o CI passo a passo; no final, coletaremos o resultado e executaremos o deploy.
Requisitos de implementação
- Inovações mínimas de servidor
- A implantação deve ser automatizada
- O ponto de entrada para a implantação é a marcação para o assembly de desenvolvimento e a confirmação manual adicional para prod
- O conjunto deve passar no teste automático
- Versão manual do mecanismo de reversão
Porquê CircleCI?
Desde o início, o projeto usou um repositório de bitbucket privado. (Agora os repositórios privados já estão no github.) Sem sair do ecossistema, a Atlasian decidiu usar o CircleCI (a seguir designado por CI). Eu gostei disso:
- configuração mínima
- recurso de depuração ssh
- versão gratuita, mas com limitações
- 2500 créditos / por semana (aproximadamente 250 minutos de conclusão) #go são coletados e implantados rapidamente, temos o suficiente
- execução de thread único # não temos muitos projetos de estimação
- somente linux e windows # precisamos do linux
Parte um, fluxo de trabalho
Crie uma pasta .circle e crie um arquivo config.yml nela e descreva o fluxo de trabalho esperado (a ordem de execução da tarefa)
workflows: version: 2 tagged-build: jobs: - test - dev_deploy: requires: - test - approve_master_deploy: type: approval requires: - test - dev_deploy - prod_deploy: requires: - dev_deploy - approve_master_deploy
Aqui está o resultado:
Descrevemos um padrão de acordo com o qual cada confirmação será verificada primeiro por testes, depois implementada no dev e, em seguida, com confirmação manual, enviada ao servidor de batalha. Para orientar o brilho, adicione um filtro para que a tarefa funcione apenas por marca.
- dev_deploy: requires: - test filters: branches: ignore: /.*/ tags: only: /.*/
O segundo passo, o mais fácil
Vamos começar executando os testes, haverá um mínimo de código.
jobs: test: docker: - image: circleci/golang:1.12 working_directory: ~/go-example/ steps: - checkout # linter' - run: go test -cover -v ./...
Depois que nosso código for testado e aprovado nas verificações de estilo de código, você poderá implantar no dev. Sugiro usar o supervisor (versão 3.1.4 no momento da redação) para iniciar o serviço go, coletaremos logs para eles.
Adicione o arquivo supervisor_ph.conf à pasta .circleci. Na estrutura do CI PH_NAME, ele mudará para o nome do projeto. E no mesmo arquivo, escreveremos a saída dos logs.
[program:PH_NAME] stopasgroup=true user=deploy-user autostart=true autorestart=true stdout_logfile=/var/log/supervisor/PH_NAME.log stderr_logfile=/var/log/supervisor/PH_NAME.log redirect_stderr=true
Tudo isso distingue nosso projeto dos outros:
Tempo de implantação
Para dev e prod, apenas os servidores são alterados e um sufixo é adicionado ao nome do aplicativo. A configuração é armazenada em variáveis de ambiente. (
Aplicações de 12 fatores ) Tiraremos essa parte do ambiente, duplicaremos o restante.
prod_deploy: environment: TARGET_IP: 0.0.0.0 TARGET_DIR: /var/www/deploy-user/go-example REMOTE_USER: deploy-user SERVICE_NAME: go_example_prod docker: - image: circleci/golang:1.12 working_directory: ~/go-example/ steps: - checkout - add_ssh_keys # ci , - run: go build -ldflags "-X main.version=$CIRCLE_TAG" -o ./main ./src/main - run: ssh -o "StrictHostKeyChecking=no" $REMOTE_USER@$TARGET_IP "mkdir $TARGET_DIR/v$CIRCLE_TAG" # , - run: scp main $REMOTE_USER@$TARGET_IP:$TARGET_DIR/v$CIRCLE_TAG/ # - run: sed "s/PH_NAME/$SERVICE_NAME/g" .circleci/supervisor_ph.conf > .circleci/$SERVICE_NAME.conf - run: echo command=$TARGET_DIR/v$CIRCLE_TAG/main >> .circleci/$SERVICE_NAME.conf - run: scp .circleci/$SERVICE_NAME.conf $REMOTE_USER@$TARGET_IP:$TARGET_DIR/v$CIRCLE_TAG/ - run: ssh $REMOTE_USER@$TARGET_IP "ln -sf $TARGET_DIR/v$CIRCLE_TAG/$SERVICE_NAME.conf /etc/supervisord.d" - run: ssh $REMOTE_USER@$TARGET_IP "supervisorctl -c /etc/supervisord.conf reread && supervisorctl -c /etc/supervisord.conf update" - run: curl "$TELEGRAM_SERVICE?msg=$SERVICE_NAME%20v$CIRCLE_TAG%20deployed&channel=go_deploy"
Para notificações, usamos nosso próprio bot, chamado através de curl. O comando `when: on_fail` funciona se algo der errado, também pode ser usado para reverter as alterações. Embora tenhamos esse bot de telegrama, mas em geral você pode ficar sem ele e usar as notificações padrão: Slack, IRC. Além disso, as notificações de erro vão para o e-mail.
A variável `$ TELEGRAM_SERVICE` é adicionada na seção BUILD SETTINGS → Environment Variables.
- run: command: curl "$TELEGRAM_SERVICE?msg=$SERVICE_NAME%20v$CIRCLE_TAG%20failed&channel=go_deploy" when: on_fail
Linha de chegada
Nós pressionamos o github ou o bitbucket. Depois vamos ao CircleCI no item Adicionar projeto
Em seguida, selecione Iniciar construção. A etapa final será adicionar uma chave ssh para autorização no servidor sob o usuário selecionado.
Tudo pode ser feito para implantar, colocar uma etiqueta e começar a aproveitar a vida. A versão final ./.circleci/config.yml -
aqui