Na Kinsta, temos projetos de todos os tamanhos para hospedagem de aplicativos, hospedagem de banco de dados e hospedagem gerenciada de WordPress.<\/p>\n
Com as solu\u00e7\u00f5es de hospedagem na nuvem da Kinsta, voc\u00ea pode implantar aplicativos<\/a> em v\u00e1rias linguagens e frameworks, como NodeJS, PHP, Ruby, Go, Scala e Python. Com um Dockerfile, voc\u00ea pode implementar qualquer aplicativo. Voc\u00ea pode conectar seu reposit\u00f3rio Git (hospedado no GitHub, GitLab ou Bitbucket) para implantar seu c\u00f3digo diretamente na Kinsta.<\/p>\n Voc\u00ea pode hospedar bancos de dados MariaDB, Redis, MySQL e PostgreSQL<\/a> prontos para uso, economizando tempo para se concentrar no desenvolvimento de seus aplicativos em vez de se preocupar com configura\u00e7\u00f5es de hospedagem.<\/p>\n E se voc\u00ea escolher nossa Hospedagem Gerenciada de WordPress<\/a>, voc\u00ea experimentar\u00e1 o poder das m\u00e1quinas do Google Cloud C2 em sua rede de n\u00edvel Premium e a seguran\u00e7a integrada do Cloudflare, tornando seus sites WordPress os mais r\u00e1pidos e seguros do mercado. Um dos maiores desafios do desenvolvimento e da manuten\u00e7\u00e3o de aplicativos nativos da nuvem de n\u00edvel empresarial \u00e9 ter uma experi\u00eancia consistente durante todo o ciclo de vida do desenvolvimento. Isso \u00e9 ainda mais dif\u00edcil para empresas remotas com equipes distribu\u00eddas que trabalham em plataformas diferentes, com configura\u00e7\u00f5es diferentes e comunica\u00e7\u00e3o ass\u00edncrona. Precisamos fornecer uma solu\u00e7\u00e3o consistente, confi\u00e1vel e escal\u00e1vel que funcione para:<\/p>\n Na Kinsta, confiamos muito no Docker<\/a> para que voc\u00ea tenha uma experi\u00eancia consistente em cada etapa, do desenvolvimento \u00e0 produ\u00e7\u00e3o. Neste artigo, mostraremos a voc\u00ea:<\/p>\n A execu\u00e7\u00e3o de um aplicativo localmente exige que os desenvolvedores preparem meticulosamente o ambiente, instalem todas as depend\u00eancias, configurem servidores e servi\u00e7os e certifiquem-se de que estejam configurados corretamente. Quando voc\u00ea executa v\u00e1rios aplicativos, isso pode ser complicado, especialmente quando se trata de projetos complexos com v\u00e1rias depend\u00eancias. Quando voc\u00ea introduz nessa vari\u00e1vel v\u00e1rios colaboradores com v\u00e1rios sistemas operacionais, o caos est\u00e1 instalado. Para evitar isso, usamos o Docker.<\/p>\n Com o Docker, voc\u00ea pode declarar as configura\u00e7\u00f5es de ambiente, instalar as depend\u00eancias e criar imagens com tudo onde deveria estar. Qualquer pessoa, em qualquer lugar, com qualquer sistema operacional, pode usar as mesmas imagens e ter a mesma experi\u00eancia que todos os outros.<\/p>\n Para come\u00e7ar, crie um arquivo Docker Compose<\/a>, Os arquivos Docker Compose s\u00e3o muito \u00fateis quando voc\u00ea tem mais de um cont\u00eainer em execu\u00e7\u00e3o e h\u00e1 depend\u00eancias entre os cont\u00eaineres.<\/p>\n Para criar seu arquivo Juntando tudo, temos um Primeiro, precisamos criar uma imagem do Docker usando Para criar seu arquivo Dica profissional: Observe que o A maioria dos nossos aplicativos e servi\u00e7os usa CI\/CD para implanta\u00e7\u00e3o. O Docker desempenha um papel importante no processo. Cada altera\u00e7\u00e3o na branch principal aciona imediatamente um pipeline de cria\u00e7\u00e3o por meio do GitHub Actions ou do CircleCI. O fluxo de trabalho geral \u00e9 muito simples: ele instala as depend\u00eancias, executa os testes, cria a imagem do Docker e a envia para o Google Container Registry (ou Artifact Registry). A parte que discutiremos neste artigo \u00e9 a etapa de build.<\/p>\n Usamos builds de m\u00faltiplos est\u00e1gios por raz\u00f5es de seguran\u00e7a e desempenho.<\/p>\n Nesta etapa, copiamos toda a base de c\u00f3digo com todo o c\u00f3digo-fonte e a configura\u00e7\u00e3o, instalamos todas as depend\u00eancias, inclusive as depend\u00eancias de desenvolvimento, e criamos o aplicativo. Voc\u00ea cria uma pasta A maioria das pessoas usa esse est\u00e1gio para o tempo de execu\u00e7\u00e3o, por estar muito pr\u00f3ximo do que precisamos para executar o aplicativo. No entanto, ainda precisamos instalar as depend\u00eancias de produ\u00e7\u00e3o, o que significa que deixamos rastros e precisamos do O \u00faltimo est\u00e1gio precisa ser o mais fino poss\u00edvel, com o m\u00ednimo de rastros. Ent\u00e3o, copiamos o aplicativo totalmente pronto da produ\u00e7\u00e3o e seguimos em frente. Deixamos de lado todas as coisas do yarn e do Esta \u00e9 a vers\u00e3o final do Observe que, em todas as etapas, come\u00e7amos a copiar os arquivos Digamos que voc\u00ea tenha alterado algo em H\u00e1 v\u00e1rias maneiras de criar uma imagem do Docker nos pipelines do CircleCI. Em nosso caso, optamos por usar Gra\u00e7as ao Docker, voc\u00ea precisa de uma configura\u00e7\u00e3o m\u00ednima para criar e enviar nosso aplicativo.<\/p>\n Como alternativa ao CircleCI, podemos usar o GitHub Actions para implantar o aplicativo continuamente. Configuramos o site A cada pequena altera\u00e7\u00e3o enviada para a branch principal, criamos e enviamos uma nova imagem do Docker para o registro.<\/p>\n Ter imagens do Docker prontas para uso para cada altera\u00e7\u00e3o tamb\u00e9m facilita a implanta\u00e7\u00e3o na produ\u00e7\u00e3o ou a revers\u00e3o caso algo d\u00ea errado. Usamos o Google Kubernetes Engine para gerenciar e servir nossos aplicativos e usamos o Google Cloud Deploy e o Pipelines de entrega para nosso processo de implanta\u00e7\u00e3o cont\u00ednua.<\/p>\n Quando a imagem do Docker \u00e9 criada ap\u00f3s cada pequena altera\u00e7\u00e3o (com o pipeline de CI mostrado acima), damos um passo adiante e implantamos a altera\u00e7\u00e3o em nosso cluster de desenvolvimento usando Isso aciona um processo de lan\u00e7amento para implementar as altera\u00e7\u00f5es em nosso cluster Kubernetes de desenvolvimento. Depois de testar e obter as aprova\u00e7\u00f5es, promovemos a altera\u00e7\u00e3o para o ambiente de teste e, em seguida, para o ambiente de produ\u00e7\u00e3o. Tudo isso \u00e9 poss\u00edvel porque temos uma imagem do Docker fina e isolada para cada altera\u00e7\u00e3o que tem quase tudo o que precisa. S\u00f3 precisamos informar \u00e0 implanta\u00e7\u00e3o qual tag voc\u00ea deve usar.<\/p>\n A equipe de controle de qualidade precisa principalmente de uma vers\u00e3o de pr\u00e9-produ\u00e7\u00e3o na nuvem dos aplicativos a serem testados. No entanto, \u00e0s vezes eles precisam executar um aplicativo pr\u00e9-criado localmente (com todas as depend\u00eancias) para testar um determinado recurso. Nesses casos, eles n\u00e3o querem ou n\u00e3o precisam passar por todo o trabalho de clonar o projeto inteiro, instalar pacotes npm, criar o aplicativo, enfrentar erros de desenvolvedor e revisar todo o processo de desenvolvimento para colocar o aplicativo em funcionamento. Agora que tudo j\u00e1 est\u00e1 dispon\u00edvel como uma imagem do Docker no Google Container Registry, tudo o que eles precisam \u00e9 de um servi\u00e7o no arquivo Docker compose:<\/p>\n Com esse servi\u00e7o, eles podem ativar o aplicativo em suas m\u00e1quinas locais usando cont\u00eaineres do Docker, executando:<\/p>\n Esse \u00e9 um grande passo para simplificar os processos de teste. Mesmo que o controle de qualidade decida testar uma tag espec\u00edfica do aplicativo, ele poder\u00e1 alterar facilmente a tag da imagem na linha 6 e executar novamente o comando Docker compose. Mesmo que voc\u00ea decida comparar diferentes vers\u00f5es do aplicativo simultaneamente, poder\u00e1 fazer isso facilmente com alguns ajustes. A maior vantagem \u00e9 manter nossa equipe de controle de qualidade longe dos desafios do desenvolvedor.<\/p>\n
\nResolvendo o desafio de criar aplicativos nativos da nuvem com uma equipe remota<\/h2>\n
\n
\n
Usando o Docker Desktop para melhorar a experi\u00eancia do desenvolvedor<\/h2>\n
Declare sua configura\u00e7\u00e3o com o Docker Compose<\/h2>\n
docker-compose.yml<\/code>. \u00c9 um arquivo de configura\u00e7\u00e3o declarativo escrito no formato YAML que informa ao Docker qual \u00e9 o estado desejado do seu aplicativo. O Docker usa essas informa\u00e7\u00f5es para configurar o ambiente para o seu aplicativo.<\/p>\ndocker-compose.yml<\/code>:<\/p>\n\n
image<\/code><\/a> como base para o nosso aplicativo. Pesquise no Docker Hub e tente encontrar uma imagem do Docker que j\u00e1 contenha as depend\u00eancias do seu aplicativo. Certifique-se de usar uma tag de imagem espec\u00edfica para evitar erros. O uso da tag latest<\/code> pode causar erros imprevistos em seu aplicativo. Voc\u00ea pode usar v\u00e1rias imagens de base para v\u00e1rias depend\u00eancias. Por exemplo, uma para o PostgreSQL<\/a> e outra para Redis<\/a>.<\/li>\nvolumes<\/code><\/a> para manter os dados em seu host, se voc\u00ea precisar. A persist\u00eancia de dados no computador host ajuda a evitar a perda de dados se os cont\u00eaineres do docker forem exclu\u00eddos ou se voc\u00ea precisar recri\u00e1-los.<\/li>\nnetworks<\/code><\/a> para isolar sua configura\u00e7\u00e3o e evitar conflitos de rede com o host e outros cont\u00eaineres. Isso tamb\u00e9m ajuda os cont\u00eaineres a se localizarem e se comunicarem facilmente uns com os outros.<\/li>\n<\/ol>\ndocker-compose.yml<\/code> que se parece com isto:<\/p>\nversion: '3.8'services:\n db:\n image: postgres:14.7-alpine3.17\n hostname: mk_db\n restart: on-failure\n ports:\n - ${DB_PORT:-5432}:5432\n volumes:\n - db_data:\/var\/lib\/postgresql\/data\n environment:\n POSTGRES_USER: ${DB_USER:-user}\n POSTGRES_PASSWORD: ${DB_PASSWORD:-password}\n POSTGRES_DB: ${DB_NAME:-main}\n networks:\n - mk_network\n redis:\n image: redis:6.2.11-alpine3.17\n hostname: mk_redis\n restart: on-failure\n ports:\n - ${REDIS_PORT:-6379}:6379\n networks:\n - mk_network\n \nvolumes:\n db_data:\n\nnetworks:\n mk_network:\n name: mk_network<\/code><\/pre>\nContaineriza\u00e7\u00e3o do aplicativo<\/h2>\n
Crie uma imagem do Docker para o seu aplicativo<\/h3>\n
Dockerfile<\/code> e, em seguida, cham\u00e1-lo a partir do docker-compose.yml<\/code>.<\/p>\nDockerfile<\/code>:<\/p>\n\n
FROM node:18.15.0-alpine3.17\n<\/code><\/pre>\n<\/li>\narm64-based<\/code>, mas precise criar uma imagem amd64<\/code>. Voc\u00ea pode fazer isso especificando o -- platform<\/code> em Dockerfile<\/code>:\nFROM --platform=amd64 node:18.15.0-alpine3.17\n<\/code><\/pre>\n<\/li>\nWORKDIR \/opt\/app \nCOPY package.json yarn.lock .\/ \nRUN yarn install \nCOPY . .<\/code><\/pre>\n<\/li>\nDockerfile<\/code> de docker-compose.yml<\/code>:\nservices:\n ...redis\n ...db\n \n app:\n build:\n context: .\n dockerfile: Dockerfile\n platforms:\n - \"linux\/amd64\"\n command: yarn dev\n restart: on-failure\n ports:\n - ${PORT:-4000}:${PORT:-4000}\n networks:\n - mk_network\n depends_on:\n - redis\n - db<\/code><\/pre>\n<\/li>\nservices:\n ... redis\n ... db\n \n build-docker:\n image: myapp\n build:\n context: .\n dockerfile: Dockerfile\n app:\n image: myapp\n platforms:\n - \"linux\/amd64\"\n command: yarn dev\n restart: on-failure\n ports:\n - ${PORT:-4000}:${PORT:-4000}\n volumes:\n - .:\/opt\/app\n - node_modules:\/opt\/app\/node_modules\n networks:\n - mk_network\n depends_on:\n - redis\n - db\n - build-docker\n \nvolumes:\n node_modules:<\/code><\/pre>\n<\/li>\n<\/ol>\nnode_modules<\/code> tamb\u00e9m est\u00e1 montado explicitamente para evitar problemas espec\u00edficos da plataforma com os pacotes. Isso significa que, em vez de usar o node_modules<\/code> no host, o cont\u00eainer Docker usa o seu pr\u00f3prio, mas o mapeia no host em um volume separado.<\/p>\nOtimizando a cria\u00e7\u00e3o de imagens de produ\u00e7\u00e3o com Integra\u00e7\u00e3o Cont\u00ednua<\/h2>\n
Cria\u00e7\u00e3o das imagens do Docker<\/h3>\n
Etapa 1: Builder<\/h4>\n
dist\/<\/code> e copia a vers\u00e3o constru\u00edda do c\u00f3digo para l\u00e1. Mas essa imagem \u00e9 muito grande, com um grande conjunto de rastros para ser usado em produ\u00e7\u00e3o. Al\u00e9m disso, como usamos registros NPM privados, tamb\u00e9m usamos nosso NPM_TOKEN<\/code> privado nesse est\u00e1gio. Portanto, definitivamente n\u00e3o queremos que esse est\u00e1gio seja exposto ao mundo externo. A \u00fanica coisa de que precisamos nesse est\u00e1gio \u00e9 a pasta dist\/<\/code>.<\/p>\nEst\u00e1gio 2: Produ\u00e7\u00e3o<\/h4>\n
NPM_TOKEN<\/code>. Portanto, esse est\u00e1gio ainda n\u00e3o est\u00e1 pronto para ser exposto. Al\u00e9m disso, preste aten\u00e7\u00e3o em yarn cache clean<\/code> na linha 19. Esse pequeno comando reduz o tamanho da nossa imagem em at\u00e9 60%.<\/p>\nEst\u00e1gio 3: Tempo de execu\u00e7\u00e3o<\/h4>\n
NPM_TOKEN<\/code> e executamos apenas o aplicativo.<\/p>\nDockerfile.production<\/code>:<\/p>\n# Stage 1: build the source code \nFROM node:18.15.0-alpine3.17 as builder \nWORKDIR \/opt\/app \nCOPY package.json yarn.lock .\/ \nRUN yarn install \nCOPY . . \nRUN yarn build \n\n# Stage 2: copy the built version and build the production dependencies FROM node:18.15.0-alpine3.17 as production \nWORKDIR \/opt\/app \nCOPY package.json yarn.lock .\/ \nRUN yarn install --production && yarn cache clean \nCOPY --from=builder \/opt\/app\/dist\/ .\/dist\/ \n\n# Stage 3: copy the production ready app to runtime \nFROM node:18.15.0-alpine3.17 as runtime \nWORKDIR \/opt\/app \nCOPY --from=production \/opt\/app\/ . \nCMD [\"yarn\", \"start\"]<\/code><\/pre>\npackage.json<\/code> e yarn.lock<\/code> primeiro, instalamos as depend\u00eancias e depois copiamos o restante da base de c\u00f3digo. O motivo \u00e9 que o Docker constr\u00f3i cada comando como uma camada sobre a anterior. E cada build pode usar as camadas anteriores, se dispon\u00edveis, e apenas construir as novas camadas para fins de desempenho.<\/p>\nsrc\/services\/service1.ts<\/code> sem tocar nos pacotes. Isso significa que as primeiras quatro camadas do construtor n\u00e3o foram tocadas e podem ser reutilizadas. Isso torna o processo de build incrivelmente mais r\u00e1pido.<\/p>\nEnviando o aplicativo para o Google Container Registry por meio de pipelines CircleCI<\/h3>\n
circleci\/gcp-gcr orbs<\/code>:<\/p>\nexecutors:\n docker-executor:\n docker:\n - image: cimg\/base:2023.03\norbs:\n gcp-gcr: circleci\/gcp-gcr@0.15.1\njobs:\n ...\n deploy:\n description: Build & push image to Google Artifact Registry\n executor: docker-executor\n steps:\n ...\n - gcp-gcr\/build-image:\n image: my-app\n dockerfile: Dockerfile.production\n tag: ${CIRCLE_SHA1:0:7},latest\n - gcp-gcr\/push-image:\n image: my-app\n tag: ${CIRCLE_SHA1:0:7},latest<\/code><\/pre>\nEnviando o aplicativo para o Google Container Registry por meio do GitHub Actions<\/h3>\n
gcloud<\/code>, criamos e enviamos a imagem do Docker para gcr.io<\/code>:<\/p>\njobs:\n setup-build:\n name: Setup, Build\n runs-on: ubuntu-latest\n\n steps:\n - name: Checkout\n uses: actions\/checkout@v3\n\n - name: Get Image Tag\n run: |\n echo \"TAG=$(git rev-parse --short HEAD)\" >> $GITHUB_ENV\n\n - uses: google-github-actions\/setup-gcloud@master\n with:\n service_account_key: ${{ secrets.GCP_SA_KEY }}\n project_id: ${{ secrets.GCP_PROJECT_ID }}\n\n - run: |-\n gcloud --quiet auth configure-docker\n\n - name: Build\n run: |-\n docker build \n --tag \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:$TAG\" \n --tag \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:latest\" \n .\n\n - name: Push\n run: |-\n docker push \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:$TAG\"\n docker push \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:latest\"<\/code><\/pre>\nImplantando mudan\u00e7as no Google Kubernetes Engine usando os pipelines de entrega do Google<\/h2>\n
gcloud<\/code>. Vamos dar uma olhada nessa etapa do pipeline do CircleCI:<\/p>\n- run:\n name: Create new release\n command: gcloud deploy releases create release-${CIRCLE_SHA1:0:7} --delivery-pipeline my-del-pipeline --region $REGION --annotations commitId=$CIRCLE_SHA1 --images my-app=gcr.io\/${PROJECT_ID}\/my-app:${CIRCLE_SHA1:0:7}<\/code><\/pre>\nComo a equipe de garantia de qualidade se beneficia desse processo<\/h2>\n
services:\n ...redis\n ...db\n \n app:\n image: gcr.io\/${PROJECT_ID}\/my-app:latest\n restart: on-failure\n ports:\n - ${PORT:-4000}:${PORT:-4000}\n environment:\n - NODE_ENV=production\n - REDIS_URL=redis:\/\/redis:6379\n - DATABASE_URL=postgresql:\/\/${DB_USER:-user}:${DB_PASSWORD:-password}@db:5432\/main\n networks:\n - mk_network\n depends_on:\n - redis\n - db<\/code><\/pre>\ndocker compose up<\/code><\/pre>\nVantagens de usar o Docker<\/h2>\n