37 KiB
Manual do DevOps
Este guia irá ajudá-lo a entender nossas ferramentas de infraestrutura e como mantemos nossas plataformas. Embora este guia não tenha muitos detalhes para todas as operações, ele pode ser usado como referência para a compreensão dos sistemas.
Fale com a gente, se você tiver algum comentário ou dúvidas, e teremos prazer em esclarecê-las.
Manual de Voo - Implementação de Código
Este repositório é continuamente construído, testado e implementado em conjuntos separados de infraestrutura (servidores, base de dados, CDNs, etc.).
Isto implica três passos a serem seguidos em sequência:
- Novas alterações (sejam consertos ou funcionalidades) são mergeadas na nossa branch principal de desenvolvimento (
main
) por meio de pull requests. - Estas alterações são executadas por uma série de testes automatizados.
- Uma vez que os testes passem, liberamos as alterações (ou as atualizamos se necessário) para implementações na nossa infraestrutura.
Compilando a base de código - mapeando branches do Git para implementações.
Normalmente, é feito um merge de main
(branch padrão de desenvolvimento) na branch production-staging
uma vez ao dia e liberada em uma infraestrutura isolada.
Esta é uma versão intermediária para nossos desenvolvedores e colaboradores voluntários. É também conhecida como a nossa versão de "preparo" (staging) ou "beta".
Ela é idêntica ao nosso ambiente de produção em freeCodeCamp.org
, tirando o fato de ela usar um conjunto separado de bancos de dados, servidores, web-proxies, etc. Este isolamento nos permite testar o desenvolvimento e as funcionalidades de forma contínua em um cenário semelhante ao de "produção", sem que os usuários regulares da plataforma principal do freeCodeCamp.org sejam afetados.
Uma vez que a equipe de desenvolvedores @freeCodeCamp/dev-team
esteja feliz com as mudanças na plataforma de preparo, essas alterações são movidas a cada poucos dias para a branch production-current
.
Esta é a versão final que move as mudanças para as nossas plataformas de produção no freeCodeCamp.org.
Testando alterações - Teste de integração e de aceitação do usuário.
Empregamos vários níveis de testes de integração e aceitação para verificar a qualidade do código. Todos os nossos testes são feitos através de software como GitHub Actions CI e Azure Pipelines.
Temos testes unitários para nossas soluções de desafio, APIs do servidor e interfaces de usuário e cliente. Eles nos ajudam a testar a integração entre diferentes componentes.
[!NOTE] Também estamos escrevendo testes de usuário finais que ajudarão a replicar cenários do mundo real, como atualizar um e-mail ou fazer uma chamada para a API ou serviços de terceiros.
Juntos, esses testes ajudam a evitar que problemas se repitam e garantem que não introduzimos um erro enquanto trabalhamos em outra falha ou recurso.
Implementando alterações - Enviando alterações para os servidores.
Nós configuramos software de entrega contínua para fazer push de mudanças no nosso servidor de desenvolvimento e produção.
Uma vez que as alterações são enviadas para as branches de lançamento protegidas, um pipeline de construção é automaticamente acionado para a branch. Os pipelines de compilação são responsáveis pela compilação de artefatos e os guardam em um armazenamento de longo prazo para uso posterior.
O pipeline de compilação aciona um correspondente pipeline de lançamento se ele completar uma execução bem-sucedida. Os pipelines de lançamento são responsáveis por coletar os artefatos de compilação, movendo-os para os servidores e deixando-os disponíveis para acesso.
Estado de compilações e lançamentos estão disponíveis aqui.
Acione uma compilação, um teste e uma implantação
Atualmente, somente membros da equipe de desenvolvedores podem dar push nas branches de produção. As alterações nas branches production-*
podem ser enviadas para upstream
apenas por meio de um fast-forward merge.
[!NOTE] Nos próximos dias, nós vamos melhorar este fluxo a ser feito por meio de pull-requests, para melhor gerenciamento de acesso e transparência.
Enviando alterações para aplicações em fase de preparo.
-
Configure seus remotes corretamente.
git remote -v
Resultados:
origin git@github.com:raisedadead/freeCodeCamp.git (fetch) origin git@github.com:raisedadead/freeCodeCamp.git (push) upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch) upstream git@github.com:freeCodeCamp/freeCodeCamp.git (push)
-
Certifique-se de que a sua branch
main
está intacta e sincronizada com a upstream.git checkout main git fetch --all --prune git reset --hard upstream/main
-
Verifique se a IC do GitHub está passando a branch
main
para o upstream.Os testes de integração contínua devem estar verdes e PASSANDO para a branch
main
. Clique na marca de verificação verde próximo ao hash do commit quando estiver visualizando o código da branchmain
.Verificando o status no GitHub Actions (captura de tela)
![Veja o estado de compilação no GitHub Actions](https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/main/docs/images/devops/github-actions.png)Se houver falhas, você deve parar e investigar os erros.
-
Confirme se você consegue compilar o repositório localmente.
npm run clean-and-develop
-
Mova as alterações da
main
para aproduction-staging
através de um fast-forward mergegit checkout prod-staging git merge main git push upstream
[!NOTE] Você não será capaz de dar um force push, e se houver reescrito o histórico de alguma forma, esses comandos vão falhar.
Se isso acontecer, pode ser que você tenha feito algo errado e você deve simplesmente começar de novo.
As etapas acima vão disparar automaticamente uma execução no pipeline de compilação para a branch production-staging
. Quando a compilação estiver completa, os artefatos são salvos como arquivos .zip
em um armazenamento de longo prazo para serem recuperados e usados mais tarde.
O pipeline de lançamento é acionado automaticamente quando um novo artefato estiver disponível a partir do pipeline de compilação conectado. Para plataformas de staging, este processo não envolve aprovação manual e os artefatos são empurrados para os servidores de CDN do cliente e API.
Enviando alterações para aplicações de produção.
O processo é quase o mesmo das plataformas de preparo, com algumas verificações extras. Só para garantir, não quebramos nada no freeCodeCamp.org que possa ver centenas de usuários usá-lo a qualquer momento.
NÃO execute esses comandos a menos que tenha verificado que tudo está funcionando na plataforma de preparo. Você não deve ignorar qualquer teste na fase de preparo antes de prosseguir. |
---|
-
Garanta que sua branch
prod-staging
esteja impecável e sincronizada com a upstream.git checkout prod-staging git fetch --all --prune git reset --hard upstream/prod-staging
-
Mova as alterações da
prod-staging
para aprod-current
através de um fast-forward mergegit checkout prod-current git merge prod-staging git push upstream
[!NOTE] Você não será capaz de forçar o push e, se você reescreveu o histórico de qualquer forma, esses comandos irão falhar.
Se falharem, você pode ter feito algo errado e deve começar de novo.
As etapas acima vão disparar automaticamente uma execução no pipeline de compilação para a branch prod-current
. Assim que um artefato de compilação estiver pronto, ele acionará uma execução no pipeline de lançamento.
Etapas adicionais para a equipe
Um release run é acionado, membros da equipe de desenvolvedores receberão um e-mail manual de intervenção automático. Eles podem aprovar ou rejeitar o release run.
Se as alterações estão funcionando bem e foram testadas na plataforma de preparo, então podem ser aprovadas. A aprovação deve ser dada no prazo de 4 horas após a liberação ser acionada antes de ser automaticamente rejeitada. Uma equipe pode acionar novamente a execução de lançamento manualmente para execuções rejeitadas ou esperar pelo próximo ciclo de lançamento.
Para uso de funcionários:
Verifique seu e-mail para obter um link direto ou vá para o painel de liberação depois que a execução da compilação estiver concluída. |
---|
Uma vez que um dos membros da equipe aprovar o lançamento, as mudanças serão feitas nos servidores CDN e API da produção do freeCodeCamp.org.
Estado de compilação, teste e implantação
Aqui está o estado atual de teste, compilação e implantação do código.
Branch | Teste de unidade | Testes de integração | Compilações & implantações |
---|---|---|---|
main |
- | ||
prod-staging |
Pipelines da Azure | ||
prod-current |
Pipelines da Azure | ||
prod-next (experimental, ainda está por vir) |
- | - | - |
Acesso antecipado e teste beta
Você é bem-vindo para testar estes lançamentos em um modo de "beta testing público" e obter acesso antecipado às funcionalidades que estão por vir. Às vezes, esses recursos/mudanças são referidos como next, beta, staging, etc. interligadamente.
Suas contribuições por meio de comentários e issues nos ajudarão a fazer as plataformas de produção do freeCodeCamp.org
mais resilientes, consistentes e estáveis para todos.
Agradecemos por relatar erros que encontra e ajuda para melhorar o freeCodeCamp.org. Você é demais!
Identificando a próxima versão das plataformas
Atualmente uma versão pública de testes beta está disponível em:
Aplicação | Linguagem | URL |
---|---|---|
Aprenda | Inglês | https://www.freecodecamp.dev |
Espanhol | https://www.freecodecamp.dev/espanol | |
Chinês | https://chinese.freecodecamp.dev | |
Novidades | Inglês | https://www.freecodecamp.dev/news |
Fórum | Inglês | https://forum.freecodecamp.dev |
Chinês | https://chinese.freecodecamp.dev/forum | |
API | - | https://api.freecodecamp.dev |
[!NOTE] O nome do domínio é diferente de
freeCodeCamp.org
. Isso é intencional para evitar que ferramentas de busca indexem e evitar confusões da parte dos usuários regulares da plataforma.A lista (não muito longa) abaixo contém todos os aplicativos que fornecemos. Nem todas as variantes das linguagens são implantadas na fase de preparação para conservar recursos.
Identificando a versão atual das plataformas
A versão atual da plataforma está sempre disponível em freeCodeCamp.org
.
O time de desenvolvimento faz o merge nas mudanças da branch prod-staging
para prod-current
quando lançam mudanças. O commit principal deve ser o que você vê no site.
Você pode identificar a versão exata implantada visitando os registros de compilação e implantação disponíveis na seção de estado. Alternativamente, você também pode entrar em contato na sala de bate-papo dos contribuidores.
Limitações conhecidas
Existem algumas limitações e desvantagens conhecidas ao usar a versão beta da plataforma.
-
Todos os dados/progresso pessoal nessas plataformas beta NÃO serão salvos ou transferidos para a produção.
Os usuários na versão beta terão uma conta separada da produção. A versão beta usa um banco de dados fisicamente separado da produção. Isso nos dá a capacidade de evitar qualquer perda acidental de dados ou modificações. A equipe de desenvolvimento pode limpar o banco de dados nesta versão beta conforme necessário.
-
Não há garantias na disponibilidade e confiabilidade das plataformas beta.
Espera-se que a implantação seja frequente e em iterações rápidas, às vezes várias vezes ao dia. Como resultado, haverá tempos de inatividade inesperados ou funcionalidades quebradas na versão beta.
-
Não envie usuários regulares para este site como uma medida de confirmar uma correção
O site beta é e sempre foi para melhorar o desenvolvimento e os testes locais, nada mais. Não é uma promessa do que está por vir, mas um vislumbre do que está sendo trabalhado.
-
O login na página pode parecer diferente da produção
Nós utilizamos um locatário de teste para o freeCodeCamp.dev no Auth 0 e, portanto, não temos a capacidade de definir um domínio personalizado. Isso faz com que todas as callbacks de redirecionamento e a página de login apareçam em um domínio padrão como:
https://freecodecamp-dev.auth0.com/
. Isso não afeta a funcionalidade e é o mais próximo da produção que conseguimos.
Relatar problemas e deixar comentário
Abra novas issues para discussões e informações sobre erros.
Você pode enviar um e-mail para dev[at]freecodecamp.org
se você tiver alguma dúvida. Como sempre, todas as vulnerabilidades de segurança devem ser relatadas à security[at]freecodecamp.org
em vez do rastreador público e fórum.
Manual de voo - Mantendo o servidor
[!WARNING]
- O guia se aplica aos membros da equipe freeCodeCamp apenas.
- Não se deve considerar que essas instruções cubram todas as possibilidades. Tenha cuidado.
Como membro da equipe, você pode ter acesso aos nossos provedores de serviços em nuvem, como Azure, Digital Ocean, etc.
Aqui estão alguns comandos úteis que você pode usar ao trabalhar com máquinas virtuais (VM), por exemplo, realizando atualizações de manutenção ou limpezas em geral.
Obtenha a lista de VMs
[!NOTE] Talvez você já tenha acesso SSH às VMs. Só isso não permitirá que você liste VMs, a menos que você tenha acesso aos portais de nuvem também.
Azure
Instale o Azure CLI az
: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
(Apenas uma vez) Instale no macOS com
homebrew
:
brew install azure-cli
(Apenas uma vez) Login:
az login
Obtenha a lista de nomes de VM e endereços IP:
az vm list-ip-addresses --output table
Digital Ocean
Instale Digital Ocean CLI doctl
: https://github.com/digitalocean/doctl#installing-doctl
(Apenas uma vez) Instale no macOS com
homebrew
:
brew install doctl
(Apenas uma vez) Login:
Autenticação e troca de contexto: https://github.com/digitalocean/doctl#authenticating-with-digitalocean
doctl auth init
Obtenha a lista de nomes de VM e endereços IP:
doctl compute droplet list --format "ID,Name,PublicIPv4"
Rodar novos recursos
Nós estamos trabalhando na criação da configuração do IaC. Enquanto isso está ocorrendo, você pode usar o portal Azure ou o Azure CLI para criar uma nova VM e outros recursos.
[!TIP] Não importa sua escolha de como gastar os recursos, nós temos alguns arquivos de configuração úteis cloud-init para ajudar você a fazer provisionamento básico de como instalar o docker ou adicionar chaves SSH, etc.
Mantenha as VMs atualizadas
Você deve manter as VMs atualizadas realizando atualizações e atualizações. Isto vai garantir que a máquina virtual está corrigida com correções de segurança mais recentes.
[!WARNING] Antes de executar estes comandos:
- Certifique-se de que a MV foi completamente fornecida e que não há etapas pós instalação sendo executadas.
- Se você estiver atualizando pacotes em uma MV que já está servindo uma aplicação, certifique-se de que a aplicação está parada/salva. Atualizações de pacotes causarão picos no uso da banda larga, memória e/ou CPU levando à falhas nas aplicações que estão sendo executadas.
Atualize informações do pacote
sudo apt update
Atualize pacotes instalados
sudo apt upgrade -y
Limpe pacotes não utilizados
sudo apt autoremove -y
Trabalhe em servidores web (Proxy)
Estamos executando instâncias equilibradas (Azure Load Balancer) para nossos servidores na web. Esses servidores estão executando NGINX, que reverte o proxy de todo o tráfego para freeCodeCamp.org a partir de várias aplicações em execução em suas próprias infraestruturas.
A configuração do NGINX está disponível neste repositório.
Primeiro instale
Provisionando VMs com o código
-
Instale o NGINX e configure a partir do repositório.
sudo su cd /var/www/html git clone https://github.com/freeCodeCamp/error-pages cd /etc/ rm -rf nginx git clone https://github.com/freeCodeCamp/nginx-config nginx cd /etc/nginx
-
Instale os certificados de origem Cloudflare e a configuração de aplicativos upstream.
Obtenha os certificados de origem Cloudflare a partir do armazenamento seguro e instale nos locais requiridos.
OU
Mova os certificados existentes:
# Localmente scp -r username@source-server-public-ip:/etc/nginx/ssl ./ scp -pr ./ssl username@target-server-public-ip:/tmp/ # Remotamente rm -rf ./ssl mv /tmp/ssl ./
Atualize as configurações upstream:
vi configs/upstreams.conf
Adicione/atualize os endereços IP do aplicativo fonte/origem.
-
Configure a rede e o firewall.
Configure o firewall da Azure e
ufw
conforme o necessário para entrar os endereços de origem. -
Adicione a MV ao pool de back-end do balanceador de carga.
Configure e adicione as regras ao balanceador de carga, se necessário. Você também pode precisar adicionar as MVs ao pool do balanceador de cargas, se necessário.
Registro e monitoramento
-
Verifique o estado do serviço NGINX usando o comando abaixo:
sudo systemctl status nginx
-
Registro e monitoramento para os servidores estão disponíveis em:
NGINX Amplify: https://amplify.nginx.com, nosso painel básico para monitoração atual. Estamos melhorando as observações com mais métricas granulares
Atualizando instâncias (Manutenção)
Configure as mudanças das instâncias do NGINX que são mantidas no GitHub, estas devem ser implantadas em cada instância assim:
- SSH na instância e digite sudo
sudo su
- Obtenha o código de configuração mais recente.
cd /etc/nginx
git fetch --all --prune
git reset --hard origin/main
- Teste e recarregue a configuração com Signals.
nginx -t
nginx -s reload
Trabalhe nas instâncias de API
- Instale ferramentas de compilação para binários node (
node-gyp
), etc.
sudo apt install build-essential
Primeira instalação
Provisionando MVs com o código
-
Instale Node LTS.
-
Atualize o
npm
instale o PM2 e a configuraçãologrotate
e inicie no bootnpm i -g npm@6 npm i -g pm2 pm2 install pm2-logrotate pm2 startup
-
Clone freeCodeCamp, configuração env e chaves.
git clone https://github.com/freeCodeCamp/freeCodeCamp.git cd freeCodeCamp git checkout prod-current # or any other branch to be deployed
-
Crie o
.env
a partir do armazenamento seguro de credenciais. -
Crie o
google-credentials.json
a partir do armazenamento seguro de credenciais. -
Instale dependências
npm ci
-
Compile o servidor
npm run ensure-env && npm run build:curriculum && npm run build:server
-
Inicie instâncias
cd api-server pm2 start ./lib/production-start.js -i max --max-memory-restart 600M --name org
Registro e monitoramento
pm2 logs
pm2 monit
Atualizando instâncias (Manutenção)
Mudanças no código devem ser implementadas na instância da API de tempos em tempos. Pode ser uma atualização contínua ou manual. A data posterior é essencial quando estão sendo realizadas mudanças ou adições variáveis de ambiente.
[!ATTENTION] Os pipelines automatizados não estão manipulando atualizações de dependências no momento. É necessário fazer uma atualização manual antes que qualquer desenvolvimento nas pipelines seja executado.
1. Atualizações manuais - Usado para atualizar dependências, variáveis de ambiente.
- Pare todas as instâncias
pm2 stop all
- Instale dependências
npm ci
- Compile o servidor
npm run ensure-env && npm run build:curriculum && npm run build:server
- Inicie instâncias
pm2 start all --update-env && pm2 logs
2. Atualizações contínuas - Usado par mudanças lógicas no código.
pm2 reload all --update-env && pm2 logs
[!NOTE] Nós estamos lidando com atualizações contínuas no código, lógico, via pipelines. Você não deve executar estes comandos. Eles estão aqui para a documentação.
Trabalhe em instâncias de cliente
- Instale ferramentas de compilação para binários node (
node-gyp
), etc.
sudo apt install build-essential
Primeira instalação
Provisionando MVs com o código
-
Instale Node LTS.
-
Atualize o
npm
e instale o PM2 e configurelogrotate
e inicie quando reiniciarnpm i -g npm@6 npm i -g pm2 npm install -g serve pm2 install pm2-logrotate pm2 startup
-
Clone a configuração de cliente, env e chaves.
git clone https://github.com/freeCodeCamp/client-config.git client cd client
Inicie instâncias placeholder para o cliente web, elas serão atualizadas com artefatos do Azure pipeline.
A fazer: Esta configuração precisa ser movida para S3 ou armazenamento Azure Blob
echo "serve -c ../../serve.json www -p 50505" >> client-start-primary.sh chmod +x client-start-primary.sh pm2 delete client-primary pm2 start ./client-start-primary.sh --name client-primary echo "serve -c ../../serve.json www -p 52525" >> client-start-secondary.sh chmod +x client-start-secondary.sh pm2 delete client-secondary pm2 start ./client-start-secondary.sh --name client-secondary
Registro e Monitoramento
pm2 logs
pm2 monit
Atualizando instâncias (Manutenção)
As alterações no código precisam ser implementadas para as instâncias de API de vez em quando. Pode ser uma atualização contínua ou manual. A data posterior é essencial quando estão sendo realizadas mudanças ou adições variáveis de ambiente.
[!ATTENTION] Os pipelines automatizados não estão manipulando atualizações de dependências no momento. É necessário fazer uma atualização manual antes que qualquer deploy nas pipelines seja executado.
1. Atualizações manuais - Usadas para atualizar dependências, variáveis de ambiente.
-
Pare todas as instâncias
pm2 stop all
-
Instale ou atualize dependências
-
Inicie instâncias
pm2 start all --update-env && pm2 logs
2. Atualizações contínuas - Usadas para mudanças lógicas no código.
pm2 reload all --update-env && pm2 logs
[!NOTE] Nós estamos lidando com atualizações contínuas no código, lógico, via pipelines. Você não deve ter a necessidade de executar esses comandos. Eles estão aqui para documentação.
Trabalhando nos servidores do chat
Nossos servidores de chat estão disponíveis com uma configuração HA recomendada na documentação Rocket.Chat. O arquivo docker-compose
para isso está disponível aqui.
Fornecemos instâncias NGINX redundantes com balanceamento de carga (Azure Load Balancer) na frente do cluster Rocket.Chat. O arquivo de configuração NGINX está disponível aqui.
Primeira instalação
Provisionando MVs com código
Cluster do NGINX:
-
Instale o NGINX e configure a partir do repositório.
sudo su cd /var/www/html git clone https://github.com/freeCodeCamp/error-pages cd /etc/ rm -rf nginx git clone https://github.com/freeCodeCamp/chat-nginx-config nginx cd /etc/nginx
-
Instale os certificados de origem Cloudflare e a configuração de aplicativos upstream.
Obtenha os certificados de origem Cloudflare a partir do armazenamento seguro e instale nos locais requiridos.
OU
Mova os certificados existentes:
# Localmente scp -r username@source-server-public-ip:/etc/nginx/ssl ./ scp -pr ./ssl username@target-server-public-ip:/tmp/ # Remotamente rm -rf ./ssl mv /tmp/ssl ./
Atualize as configurações Upstream:
vi configs/upstreams.conf
Adicione/atualize os endereços IP do aplicativo fonte/origem.
-
Configure a rede e o firewall.
Configure o firewall da Azure e
ufw
conforme necessário para entrar os endereços de origem. -
Adicione a MV ao pool de back-end do balanceador de carga.
Configure e adicione as regras ao balanceador de carga, se necessário. Você também pode precisar adicionar as MVs ao pool do balanceador de cargas, se necessário.
Cluster do Docker:
-
Instale o Docker e configure a partir do repositório
git clone https://github.com/freeCodeCamp/chat-config.git chat cd chat
-
Configure as variáveis de ambiente necessárias e as instâncias dos endereços de IP.
-
Execute rocket-chat server
docker-compose config docker-compose up -d
Registro e monitoramento
-
Verifique o estado do serviço NGINX usando o comando abaixo:
sudo systemctl status nginx
-
Verifique o estado das instâncias do Docker que estão sendo executadas com:
docker ps
Atualizando instâncias (Manutenção)
Cluster do NGINX:
As alterações na configuração das nossas instâncias NGINX são mantidas no GitHub, elas devem ser implantadas em cada instância assim:
-
SSH na instância e digite sudo
sudo su
-
Obtenha o código de configuração mais recente.
cd /etc/nginx git fetch --all --prune git reset --hard origin/main
-
Teste e recarregue a configuração com Signals.
nginx -t nginx -s reload
Cluster do Docker:
-
SSH na instância e vá para onde está o arquivo de configuração do chat
cd ~/chat
-
Obtenha o código de configuração mais recente.
git fetch --all --prune git reset --hard origin/main
-
Obtenha a imagem docker mais recente do Rocket.Chat
docker-compose pull
-
Atualize as instâncias que estão executando
docker-compose up -d
-
Veja se as instâncias estão executando
docker ps
-
Limpe recursos estranhos
docker system prune --volumes
Resultado:
AVISO! Isso removerá - todos os containers parados - todas as redes que não estão sendo usadas por pelo menos um container - todos os volumes que não estão sendo usados por pelo menos um container - todas as imagens pendentes - todos os caches de compilação pendentes Tem certeza que deseja continuar? [y/N] y
Selecione sim (y) para remover tudo que não está sendo usado. Isso vai remover todos os containers parados, todas as redes e volumes não usados por pelo menos um container e imagens pendentes e caches de compilação.
Atualize as versões do Node.js nas MVs
Liste as versões do node e do npm instaladas
nvm -v
node -v
npm -v
nvm ls
Instale a versão LTS Node.js mais recente e reinstale qualquer pacote global
nvm install 'lts/*' --reinstall-packages-from=default
Verifique os pacotes instalados
npm ls -g --depth=0
Crie um alias da versão default
do Node.js para a versão current LTS
nvm alias default lts/*
(Opcional) Desinstale versões antigas
nvm uninstall <version>
[!WARNING] Se estiver usando PM2 para os processos você também vai precisar executar as aplicações e salvar a lista de processos para restaurações automáticas quando reiniciar.
Comandos rápidos PM2 para listar, reviver processos salvos, etc.
pm2 ls
pm2 resurrect
pm2 save
pm2 logs
[!ATTENTION] Para aplicações de client, o script de shell não pode ser revivido entre as versões do Node.js com
pm2 resurrect
. Implante processos de zero ao invés disso. Isso deve melhorar quando mudarmos para uma configuração baseada em docker.
Instalando e atualizando agentes do Azure Pipeline
Veja: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops e siga as instruções para parar, remover e reinstalar os agentes. Em resumo, você pode seguir as etapas listadas aqui.
Você vai precisar de um PAT, que você pode pegar nesse link: https://dev.azure.com/freeCodeCamp-org/_usersSettings/tokens
Instalando agentes em alvos de implantação
Vá para Azure Devops e registre o agente do zero nos grupos de implantação necessários.
[!NOTE] Você deve executar os scripts no diretório principal e garantir que nenhum outro diretório
azagent
existe.
Atualizando agentes
Atualmente, atualizar os agentes requer que sejam removidos e reconfigurados. Isso é necessário para que eles tenham os valores do PATH
e de outras variáveis de ambiente corretos. Precisamos fazer isso, por exemplo, para atualizar Node.js em nossas MVs de implantação.
-
Vá e verifique o estado do serviço
cd ~/azagent sudo ./svc.sh status
-
Pare o serviço
sudo ./svc.sh stop
-
Desinstale o serviço
sudo ./svc.sh uninstall
-
Remova o agente da piscina pipeline
./config.sh remove
-
Remova os arquivos de configuração
cd ~ rm -rf ~/azagent
Uma vez que você completar as etapas acima, você pode repetir as mesmas etapas na instalação do agente.
Manual de Vôo - Disparo de e-mail
Nós usamos uma ferramenta de linha de comando para enviar a newsletter semanal. Para começar o processo:
-
Se inscreva na DigitalOcean, e inicie o use de novas droplets sob o projeto
Sendgrid
. Use uma snapshot da Sendgrid no Ubuntu com a data mais recente. Isso vem pré-instalado com a ferramenta da linha de comando para pegar e-mails da base de dados. Com o volume atual, três droplets são suficientes para enviar emails de forma oportuna. -
Configure o script para pegar a lista de email.
cd /home/freecodecamp/scripts/emails cp sample.env .env
Você vai precisar substituir os valores padrão dentro do arquivo
.env
com suas credenciais. -
Rode o script.
node get-emails.js emails.csv
Isso vai salvar a lista de email em um arquivo
emails.csv
. -
Divida os e-mails em vários arquivos, dependendo do número de droplets que você precisa. Isso fica mais fácil usando
scp
para baixar a lista de e-mails localmente e usar seu editor de texto favorito para dividi-los em múltiplos arquivos. Cada arquivo precisará do cabeçalhoemail,unsubscribeId
. -
Mude para o diretório CLI com
cd /home/sendgrid-email-blast
e configure a ferramenta conforme a documentação. -
Execute a ferramenta para enviar os e-mails, seguindo a documentação.
-
Quando o disparo de email estiver completo, verifique se nenhum e-mail falhou antes de destruir os droplets.