One place for hosting & domains

      implantar

      Como implantar um aplicativo Django escalável e seguro com o Kubernetes


      Introdução

      Neste tutorial, você irá implantar um aplicativo de pesquisa do Django em contêiner em um cluster do Kubernetes.

      O Django é um framework Web poderoso, que pode ajudar a acelerar a implantação do seu aplicativo Python. Ele inclui diversas funcionalidades convenientes, como um mapeador relacional do objeto, autenticação de usuário e uma interface administrativa personalizável para seu aplicativo. Ele também inclui um framework de cache e encoraja o design de aplicativos organizados através do seu URL Dispatcher e Sistema de modelos.

      Em Como construir um aplicativo Django e Gunicorn com o Docker, o aplicativo Polls de tutorial do Django foi modificado de acordo com a metodologia do Twelve-Factor para a construção de aplicativos Web escaláveis e nativos na nuvem. Essa configuração em contêiner foi dimensionada e protegida com um proxy reverso do Nginx e autenticada pelo Let’s Encrypt com certificados TLS seguindo Como dimensionar e proteger um aplicativo Django com o Docker, Nginx e Let’s Encrypt. Neste tutorial final da série De contêineres ao Kubernetes com o Django, o aplicativo modernizado de pesquisa do Django será implantado em um cluster do Kubernetes.

      O Kubernetes é um orquestrador de contêineres de código aberto poderoso, que automatiza a implantação, dimensionamento e gerenciamento de aplicativos em contêiner. Os objetos do Kubernetes como os ConfigMaps e Segredos permitem centralizar e desacoplar a configuração dos seus contêineres, enquanto os controladores como Deployments reiniciam automaticamente contêineres que falharam e habilitam o dimensionamento rápido de réplicas de contêineres. A criptografia TLS é habilitada com um objeto Ingress e o Controlador Ingress de código aberto ingress-nginx. O add-on cert-manager do Kubernetes renova e emite certificados usando a autoridade de certificação gratuita Let’s Encrypt.

      Pré-requisitos

      Para seguir este tutorial, será necessário:

      • Um cluster do Kubernetes 1.15+ com controle de acesso baseado na função (RBAC) habilitado. Essa configuração irá usar um cluster do Kubernetes da DigitalOcean, mas você pode criar um cluster usando outro método.
      • A ferramenta kubectl de linha de comando instalada em sua máquina local e configurada para se conectar ao seu cluster. Você pode ler mais sobre como instalar o kubectl na documentação oficial. Se você estiver usando um cluster do Kubernetes da DigitalOcean, consulte Como se conectar a um cluster do Kubernetes da DigitalOcean para aprender como se conectar ao seu cluster usando o kubectl.
      • Um nome de domínio registrado. Este tutorial usará your_domain.com do início ao fim. Você pode obter um domínio gratuitamente através do Freenom, ou usar o registrador de domínios de sua escolha.
      • Um Controlador Ingress ingress-nginx e o gerenciador de certificados TLS cert-manager instalados no seu cluster e configurados para emitir certificados TLS. Para aprender como instalar e configurar um Ingress com o cert-manager, consulte Como configurar um Nginx Ingress com Cert-Manager no Kubernetes da plataforma DigitalOcean.
      • Um registro de DNS A com your_domain.com apontando para o endereço IP público do Balanceador de carga do Ingress. Se estiver usando a DigitalOcean para gerenciar os registros de DNS do seu domínio, consulte Como gerenciar os registros de DNS para aprender como criar um registro A.
      • Um bucket de armazenamento de objetos S3, como um espaço da DigitalOcean para armazenar os arquivos estáticos do seu projeto Django e um conjunto de chaves de acesso para esse espaço. Para aprender como criar um espaço, consulte a documentação de produto Como criar espaços. Para aprender como criar chaves de acesso para espaços, consulte Compartilhando acesso a espaços com chaves de acesso. Com pequenas alterações, você pode usar qualquer serviço de armazenamento de objetos que o plug-in django-storages suporte.
      • Uma instância de servidor PostgreSQL, banco de dados e usuário para seu aplicativo Django. Com pequenas alterações, você pode usar qualquer banco de dados compatível com o Django.
      • Uma conta do Docker Hub e repositório público. Para obter mais informações sobre a criação deles, consulte Repositórios da documentação do Docker.
      • O mecanismo Docker instalado em sua máquina local. Consulte Como instalar e usar o Docker no Ubuntu 18.04 para aprender mais.

      Assim que tiver esses componentes configurados, tudo estará pronto para seguir o guia.

      Passo 1 — Clonando e configurando o aplicativo

      Neste passo, vamos clonar o código do aplicativo do GitHub e definir algumas configurações como as credenciais de banco de dados e chaves de armazenamento de objetos.

      O código do aplicativo e o Dockerfile podem ser encontrados na ramificação polls-docker do repositório GitHub do aplicativo Polls de tutorial do Django. Esse repositório contém códigos para o aplicativo de amostra Polls da documentação do Django, que ensina como construir um aplicativo de pesquisa a partir do zero.

      A ramificação polls-docker contém uma versão em Docker do aplicativo Polls. Para aprender como o aplicativo Polls foi modificado para funcionar efetivamente em um ambiente em contêiner, consulte Como construir um aplicativo Django e Gunicorn com o Docker.

      Comece usando o git para clonar o branch polls-docker do repositório GitHub do aplicativo Polls do tutorial do Django em sua máquina local:

      • git clone --single-branch --branch polls-docker https://github.com/do-community/django-polls.git

      Navegue até o diretório django-polls:

      Esse diretório contém o código Python do aplicativo Django, um Dockerfile que o Docker usará para compilar a imagem do contêiner, bem como um arquivo env que contém uma lista de variáveis de ambiente a serem passadas para o ambiente de execução do contêiner. Verifique o Dockerfile:

      Output

      FROM python:3.7.4-alpine3.10 ADD django-polls/requirements.txt /app/requirements.txt RUN set -ex && apk add --no-cache --virtual .build-deps postgresql-dev build-base && python -m venv /env && /env/bin/pip install --upgrade pip && /env/bin/pip install --no-cache-dir -r /app/requirements.txt && runDeps="$(scanelf --needed --nobanner --recursive /env | awk '{ gsub(/,/, "nso:", $2); print "so:" $2 }' | sort -u | xargs -r apk info --installed | sort -u)" && apk add --virtual rundeps $runDeps && apk del .build-deps ADD django-polls /app WORKDIR /app ENV VIRTUAL_ENV /env ENV PATH /env/bin:$PATH EXPOSE 8000 CMD ["gunicorn", "--bind", ":8000", "--workers", "3", "mysite.wsgi"]

      Esse Dockerfile usa a imagem Docker oficial do Python 3.7.4 como base e instala os requisitos de pacote Python do Django e do Gunicorn, conforme definido no arquivo django-polls/requirements.txt. Em seguida, ele remove alguns arquivos de compilação desnecessários, copia o código do aplicativo na imagem e define o PATH de execução. Por fim, ele declara que a porta 8000 será usada para aceitar conexões de contêiner recebidas e executa gunicorn com 3 trabalhadores, escutando na porta 8000.

      Para aprender mais sobre cada um dos passos nesse Dockerfile, confira o Passo 6 de Como construir um aplicativo Django e Gunicorn com o Docker.

      Agora, crie a imagem usando o docker build:

      Nós demos o nome de polls para a imagem usando o sinalizador -t e passamos o diretório atual como um contexto de compilação, que é o conjunto de arquivos de referência ao compilar a imagem.

      Depois que o Docker compilar e marcar a imagem, liste as imagens disponíveis usando docker images:

      Você deve ver a imagem polls listada:

      OutputREPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
      polls               latest              80ec4f33aae1        2 weeks ago         197MB
      python              3.7.4-alpine3.10    f309434dea3a        8 months ago        98.7MB
      

      Antes de executarmos o contêiner Django, precisamos configurar seu ambiente de execução usando o arquivo env presente no diretório atual. Esse arquivo será passado para o comando docker run usado para executar o contêiner, e o Docker irá injetar as variáveis de ambiente configuradas no ambiente de execução do contêiner.

      Abra o arquivo env com o nano ou com o seu editor favorito:

      django-polls/env

      DJANGO_SECRET_KEY=
      DEBUG=True
      DJANGO_ALLOWED_HOSTS=
      DATABASE_ENGINE=postgresql_psycopg2
      DATABASE_NAME=polls
      DATABASE_USERNAME=
      DATABASE_PASSWORD=
      DATABASE_HOST=
      DATABASE_PORT=
      STATIC_ACCESS_KEY_ID=
      STATIC_SECRET_KEY=
      STATIC_BUCKET_NAME=
      STATIC_ENDPOINT_URL=
      DJANGO_LOGLEVEL=info
      

      Preencha os valores que estão faltando para as seguintes chaves:

      • DJANGO_SECRET_KEY: defina isso como um valor único e imprevisível, conforme detalhado na documentação do Django. Um método para gerar essa chave é fornecido em Ajustando as configurações do aplicativo do tutorial sobre o Aplicativo Django escalável.
      • DJANGO_ALLOWED_HOSTS: essa variável protege o aplicativo e impede ataques de cabeçalho de host HTTP. Para fins de teste, defina isso como *, um coringa que irá corresponder a todos os hosts. Na produção, isso deve ser definido como your_domain.com. Para aprender mais sobre esse ajuste do Django, consulte as Core Settings da documentação do Django.
      • DATABASE_USERNAME: defina isso como o usuário do banco de dados PostgreSQL criado nos passos pré-requisitos.
      • DATABASE_NAME: defina isso como polls ou o nome do banco de dados PostgreSQL criado nos passos pré-requisitos.
      • DATABASE_PASSWORD: defina isso como a senha do usuário do banco de dados PostgreSQL criada nos passos pré-requisitos.
      • DATABASE_HOST: defina isso como o nome do host do seu banco de dados.
      • DATABASE_PORT: defina isso como a porta do seu banco de dados.
      • STATIC_ACCESS_KEY_ID: defina isso como a chave de acesso do seu espaço ou armazenamento de objetos.
      • STATIC_SECRET_KEY: defina isso como o segredo da chave de acesso do seu espaço ou armazenamento de objetos.
      • STATIC_BUCKET_NAME: defina isso como seu nome de espaço ou bucket de armazenamento de objetos.
      • STATIC_ENDPOINT_URL: defina isso como o URL do ponto de extremidade do espaço apropriado ou armazenamento de objetos, como https://your_space_name.nyc3.digitaloceanspaces.com se o espaço estiver localizado na região nyc3.

      Assim que terminar a edição, salve e feche o arquivo.

      No próximo passo, vamos executar o contêiner configurado localmente e criar o esquema de banco de dados. Além disso, vamos carregar ativos estáticos como folhas de estilos e imagens para o armazenamento de objetos.

      Passo 2 — Criando o esquema de banco de dados e carregando ativos para o armazenamento de objetos

      Com o contêiner construído e configurado, use o docker run para substituir o conjunto CMD no Dockerfile e criar o esquema de banco de dados usando os comandos manage.py makemigrations e manage.py migrate:

      • docker run --env-file env polls sh -c "python manage.py makemigrations && python manage.py migrate"

      Executamos a imagem de contêiner polls:latest, passamos o arquivo de variável de ambiente que acabamos de modificar e substituímos o comando do Dockerfile com sh -c "python manage.py makemigrations && python manage.py migrate", o que irá criar o esquema de banco de dados definido pelo código do aplicativo.

      Se estiver executando isso pela primeira vez, você deve ver:

      Output

      No changes detected Operations to perform: Apply all migrations: admin, auth, contenttypes, polls, sessions Running migrations: Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying admin.0001_initial... OK Applying admin.0002_logentry_remove_auto_add... OK Applying admin.0003_logentry_add_action_flag_choices... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying auth.0007_alter_validators_add_error_messages... OK Applying auth.0008_alter_user_username_max_length... OK Applying auth.0009_alter_user_last_name_max_length... OK Applying auth.0010_alter_group_name_max_length... OK Applying auth.0011_update_proxy_permissions... OK Applying polls.0001_initial... OK Applying sessions.0001_initial... OK

      Isso indica que o esquema de banco de dados foi criado com sucesso.

      Se estiver executando migrate uma outra vez, o Django irá cancelar a operação a menos que o esquema de banco de dados tenha sido alterado.

      Em seguida, vamos executar outra instância do contêiner de aplicativo e usar um shell interativo dentro dela para criar um usuário administrativo para o projeto Django.

      • docker run -i -t --env-file env polls sh

      Isso lhe fornecerá um prompt do shell dentro do contêiner em execução que você pode usar para criar o usuário do Django:

      • python manage.py createsuperuser

      Digite um nome de usuário, endereço de e-mail e senha para o seu usuário e, depois de criá-lo, pressione CTRL+D para sair do contêiner e encerrá-lo.

      Por fim, vamos gerar os arquivos estáticos para o aplicativo e fazer o upload deles para o espaço da DigitalOcean usando o collectstatic. Observe que esse processo pode demorar um pouco de tempo para ser concluído.

      • docker run --env-file env polls sh -c "python manage.py collectstatic --noinput"

      Depois que esses arquivos forem gerados e enviados, você receberá a seguinte saída.

      Output

      121 static files copied.

      Agora, podemos executar o aplicativo:

      • docker run --env-file env -p 80:8000 polls

      Output

      [2019-10-17 21:23:36 +0000] [1] [INFO] Starting gunicorn 19.9.0 [2019-10-17 21:23:36 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1) [2019-10-17 21:23:36 +0000] [1] [INFO] Using worker: sync [2019-10-17 21:23:36 +0000] [7] [INFO] Booting worker with pid: 7 [2019-10-17 21:23:36 +0000] [8] [INFO] Booting worker with pid: 8 [2019-10-17 21:23:36 +0000] [9] [INFO] Booting worker with pid: 9

      Aqui, executamos o comando padrão definido no Dockerfile, gunicorn --bind :8000 --workers 3 mysite.wsgi:application e expomos a porta do contêiner 8000 para que a porta 80 na sua máquina local seja mapeada para a porta 8000 do contêiner polls.

      Agora, você deve ser capaz de navegar até o aplicativo polls usando seu navegador Web digitando http://localhost na barra de URL. Como não há nenhuma rota definida para o caminho /, você provavelmente receberá um erro 404 Page Not Found, o que é esperado.

      Navegue até http://localhost/polls para ver a interface do aplicativo Polls:

      Interface do aplicativo Polls

      Para visualizar a interface administrativa, visite http://localhost/admin. Você deve ver a janela de autenticação do administrador do aplicativo Polls:

      Página de autenticação de administrador do Polls

      Digite o nome e a senha do usuário administrativo que você criou com o comando createsuperuser.

      Depois de autenticar-se, você pode acessar a interface administrativa do aplicativo Polls:

      Interface administrativa principal do Polls

      Observe que os ativos estáticos para os aplicativos admin e polls estão sendo entregues diretamente do armazenamento de objetos. Para confirmar isso, consulte Testando a entrega de arquivos estáticos de espaços.

      Quando terminar de explorar, aperte CTRL+C na janela do terminal executando o contêiner Docker para encerrar o contêiner.

      Com a imagem Docker do aplicativo Django testada, ativos estáticos carregados no armazenamento de objetos e o esquema de banco de dados configurado e pronto para ser usado com seu aplicativo, tudo está pronto para carregar sua imagem do aplicativo Django em um registro de imagem como o Docker Hub.

      Passo 3 — Enviando a imagem do aplicativo Django para o Docker Hub

      Para implementar seu aplicativo no Kubernetes, sua imagem de aplicativo deve ser carregada em um registro como o Docker Hub. O Kubernetes irá puxar a imagem do aplicativo do seu repositório e implantá-la em seu cluster.

      É possível usar um registro privado do Docker, como o registro do contêiner da DigitalOcean, atualmente gratuito em acesso antecipado, ou um registro público do Docker como o Docker Hub. O Docker Hub também permite criar repositórios privados do Docker. Um repositório público permite que qualquer pessoa veja e puxe as imagens do contêiner, enquanto um repositório privado permite restringir o acesso a você e seus membros de equipe.

      Neste tutorial, vamos enviar a imagem do Django ao repositório público do Docker Hub criado nos pré-requisitos. Também é possível enviar sua imagem a um repositório privado, mas puxar imagens de um repositório privado está além do escopo deste artigo. Para aprender mais sobre a autenticação do Kubernetes com o Docker Hub e puxar imagens privadas, consulte Puxar uma imagem de um registro privado dos documentos do Kubernetes.

      Comece fazendo login no Docker Hub em sua máquina local:

      Output

      Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one. Username:

      Digite seu nome de usuário e senha do Docker Hub para fazer login.

      A imagem do Django possui atualmente o sinalizador polls:latest. Para enviá-la ao seu repositório do Docker Hub, sinalize novamente a imagem com seu nome de usuário e nome de repositório do Docker Hub:

      • docker tag polls:latest your_dockerhub_username/your_dockerhub_repo_name:latest

      Carregue a imagem no repositório:

      • docker push sammy/sammy-django:latest

      Neste tutorial, o nome de usuário do Docker Hub é sammy e o nome do repositório é sammy-django. Você deve substituir esses valores pelo seu nome de usuário e nome de repositório do Docker Hub.

      Você verá um resultado que se atualiza conforme as camadas da imagem são enviadas ao Docker Hub.

      Agora que sua imagem está disponível no Kubernetes no Docker Hub, você pode começar a implantá-la em seu cluster.

      Passo 4 — Configurando o ConfigMap

      Quando executamos o contêiner do Django localmente, passamos o arquivo env ao docker run para injetar variáveis de configuração no ambiente de tempo de execução. No Kubernetes, as variáveis de configuração podem ser injetadas usando o ConfigMaps e Segredos.

      Os ConfigMaps devem ser usados para armazenar informações de configuração não confidenciais, como as configurações do aplicativo, enquanto os Segredos devem ser usados para informações confidenciais como chaves de API e credenciais de banco de dados. Ambos são injetados em contêineres de maneira similar, mas os Segredos têm recursos de controle de acesso e segurança adicionais, como a criptografia em repouso. Os Segredos também armazenam dados em base64, enquanto os ConfigMaps armazenam dados em texto simples.

      Para começar, crie um diretório chamado yaml no qual vamos armazenar nossos manifestos do Kubernetes. Navegue até o diretório.

      Abra um arquivo chamado polls-configmap.yaml no nano ou seu editor de texto preferido:

      • nano polls-configmap.yaml

      Cole o seguinte manifesto do ConfigMap:

      polls-configmap.yaml

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: polls-config
      data:
        DJANGO_ALLOWED_HOSTS: "*"
        STATIC_ENDPOINT_URL: "https://your_space_name.space_region.digitaloceanspaces.com"
        STATIC_BUCKET_NAME: "your_space_name"
        DJANGO_LOGLEVEL: "info"
        DEBUG: "True"
        DATABASE_ENGINE: "postgresql_psycopg2"
      

      As configurações não confidenciais foram extraídas do arquivo env modificado no Passo 1 e coladas em um manifesto do ConfigMap. O objeto do ConfigMap chama-se polls-config. Copie os mesmos valores inseridos no arquivo env no passo anterior.

      Por motivos de teste, deixe o DJANGO_ALLOWED_HOSTS como * para desativar a filtragem baseada em cabeçalhos de host. Em um ambiente de produção, isso deve ser definido como o domínio do seu aplicativo.

      Quando terminar de editar o arquivo, salve e feche-o.

      Crie o ConfigMap em seu cluster usando o kubectl apply:

      • kubectl apply -f polls-configmap.yaml

      Output

      configmap/polls-config created

      Com o ConfigMap criado, vamos criar o Segredo usado pelo nosso aplicativo no próximo passo.

      Passo 5 — Configurando o Segredo

      Os valores do Segredo devem ser codificados em base64, o que significa que criar objetos Segredo em seu cluster é ligeiramente mais complicado do que criar ConfigMaps. É possível repetir o processo do passo anterior, manualmente codificar os valores do Segredo em base64 e colá-los em um arquivo de manifesto. Também é possível criá-los usando um arquivo de variável de ambiente, kubectl create e o sinalizador --from-env-file, o que será feito neste passo.

      Novamente, vamos usar o arquivo env do Passo 1, removendo variáveis inseridas no ConfigMap. Faça uma cópia do arquivo env chamado polls-secrets no diretório yaml:

      • cp ../env ./polls-secrets

      Edite o arquivo em seu editor de preferência:

      polls-secrets

      DJANGO_SECRET_KEY=
      DEBUG=True
      DJANGO_ALLOWED_HOSTS=
      DATABASE_ENGINE=postgresql_psycopg2
      DATABASE_NAME=polls
      DATABASE_USERNAME=
      DATABASE_PASSWORD=
      DATABASE_HOST=
      DATABASE_PORT=
      STATIC_ACCESS_KEY_ID=
      STATIC_SECRET_KEY=
      STATIC_BUCKET_NAME=
      STATIC_ENDPOINT_URL=
      DJANGO_LOGLEVEL=info
      

      Exclua todas as variáveis inseridas no manifesto do ConfigMap. Quando terminar, ele deve ficar parecido com isto:

      polls-secrets

      DJANGO_SECRET_KEY=your_secret_key
      DATABASE_NAME=polls
      DATABASE_USERNAME=your_django_db_user
      DATABASE_PASSWORD=your_django_db_user_password
      DATABASE_HOST=your_db_host
      DATABASE_PORT=your_db_port
      STATIC_ACCESS_KEY_ID=your_space_access_key
      STATIC_SECRET_KEY=your_space_access_key_secret
      

      Certifique-se de usar os mesmos valores usados no Passo 1. Quando terminar, salve e feche o arquivo.

      Crie o Segredo em seu cluster usando o kubectl create secret:

      • kubectl create secret generic polls-secret --from-env-file=poll-secrets

      Output

      secret/polls-secret created

      Aqui, criamos um objeto Segredo chamado polls-secret e o passamos no arquivo de Segredos que acabamos de criar.

      Verifique o Segredo usando o kubectl describe:

      • kubectl describe secret polls-secret

      Output

      Name: polls-secret Namespace: default Labels: <none> Annotations: <none> Type: Opaque Data ==== DATABASE_PASSWORD: 8 bytes DATABASE_PORT: 5 bytes DATABASE_USERNAME: 5 bytes DJANGO_SECRET_KEY: 14 bytes STATIC_ACCESS_KEY_ID: 20 bytes STATIC_SECRET_KEY: 43 bytes DATABASE_HOST: 47 bytes DATABASE_NAME: 5 bytes

      Neste ponto, você armazenou a configuração do seu aplicativo em seu cluster do Kubernetes usando os tipos de objeto Segredo e ConfigMap. Agora, estamos prontos para implantar o aplicativo no cluster.

      Passo 6 — Implementando o aplicativo do Django usando uma Implantação

      Neste passo, você criará um Deployment (implantação) para seu aplicativo do Django. Uma Implantação do Kubernetes é um controlador que pode ser usado para gerenciar aplicativos sem estado em seu cluster. Um controlador é um loop de controle que regula cargas de trabalho aumentando ou diminuindo-as. Os controladores também reiniciam e limpam contêineres com falhas.

      As Implantações controlam um ou mais Pods, a menor unidade implantável em um cluster do Kubernetes. Os Pods incluem um ou mais contêineres. Para aprender mais sobre os diferentes tipos de cargas de trabalho que você pode inicializar, consulte Uma introdução ao Kubernetes.

      Inicie abrindo um arquivo chamado polls-deployment.yaml no seu editor de texto favorito:

      • nano polls-deployment.yaml

      Cole o manifesto de Implantação a seguir:

      polls-deployment.yaml

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: polls-app
        labels:
          app: polls
      spec:
          replicas: 2
        selector:
          matchLabels:
            app: polls
        template:
          metadata:
            labels:
              app: polls
          spec:
            containers:
              - image: your_dockerhub_username/app_repo_name:latest
                name: polls
                envFrom:
                - secretRef:
                    name: polls-secret
                - configMapRef:
                    name: polls-config
                ports:
                  - containerPort: 8000
                    name: gunicorn
      

      Preencha o nome apropriado da imagem do contêiner, referenciando a imagem do Polls do Django que você enviou para o Docker Hub no Passo 2.

      Aqui, definimos uma Implantação do Kubernetes chamada polls-app e a rotulamos com o par de chave-valor app: polls. Especificamos que queremos executar duas réplicas do Pod definido abaixo do campo template.

      Usando o envFrom com o secretRef e o configMapRef, especificamos que todos os dados do Segredo polls-secret e do ConfigMap polls-config devem ser injetados nos contêineres como variáveis de ambiente. As chaves ConfigMap e Segredo tornam-se os nomes das variáveis de ambiente.

      Por fim, expomos a containerPort 8000 e a nomeamos gunicorn.

      Para aprender mais sobre como configurar as Implantações do Kubernetes, consulte Deployments na documentação do Kubernetes.

      Quando terminar de editar o arquivo, salve e feche-o.

      Crie uma Implantação no seu cluster usando o kubectl apply -f:

      • kubectl apply -f polls-deployment.yaml
      • deployment.apps/polls-app created

      Verifique se a Implantação foi implantada corretamente usando o kubectl get:

      • kubectl get deploy polls-app

      Output

      NAME READY UP-TO-DATE AVAILABLE AGE polls-app 2/2 2 2 6m38s

      Se encontrar um erro ou algo não estiver funcionando, use o kubectl describe para verificar o Deployment que falhou:

      Verifique os dois Pods usando o kubectl get pod:

      Output

      NAME READY STATUS RESTARTS AGE polls-app-847f8ccbf4-2stf7 1/1 Running 0 6m42s polls-app-847f8ccbf4-tqpwm 1/1 Running 0 6m57s

      Agora, duas réplicas do seu aplicativo Django estão em funcionamento no cluster. Para acessar o aplicativo, é necessário criar um Service (serviço) do Kubernetes, que vamos fazer em seguida.

      Passo 7 — Permitindo o acesso externo usando um Serviço

      Neste passo, você irá criar um Serviço para seu aplicativo Django. Um Serviço do Kubernetes é uma abstração que permite expor um conjunto de Pods em execução como um serviço de rede. Ao usar um Serviço, é possível criar um ponto de extremidade estável para seu aplicativo que não muda à medida que os Pods são destruídos e recriados.

      Existem vários tipos de Serviço, incluindo os Serviços de ClusterIP, que expõem o Serviço em um IP interno do cluster, os Serviços de NodePort, que expõem o Serviço em cada nó em uma porta estática chamada NodePort, além de os Serviços de LoadBalancer, que fornecem um balanceador de carga em nuvem para direcionar o tráfego externo aos Pods no seu cluster (através dos NodePorts, criados por ele automaticamente). Para aprender mais sobre isso, consulte Service nos documentos do Kubernetes.

      Em nossa configuração final, vamos usar um Serviço de ClusterIP que é exposto usando um Ingress e um Controlador Ingress configurados nos pré-requisitos deste guia. Por enquanto, para testar se tudo está funcionando corretamente, vamos criar um Serviço de NodePort temporário para acessar o aplicativo Django.

      Inicie criando um arquivo chamado polls-svc.yaml usando seu editor favorito:

      Cole o manifesto de Serviço a seguir:

      polls-svc.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: polls
        labels:
          app: polls
      spec:
        type: NodePort
        selector:
          app: polls
        ports:
          - port: 8000
            targetPort: 8000
      

      Aqui, criamos um Serviço de NodePort chamado polls e damos a ele o rótulo app: polls. Em seguida, selecionamos os Pods de backend com o rótulo app: polls e miramos em suas portas 8000.

      Quando terminar de editar o arquivo, salve e feche-o.

      Implemente o Serviço usando o kubectl apply:

      • kubectl apply -f polls-svc.yaml

      Output

      service/polls created

      Confirme se seu Serviço foi criado usando o kubectl get svc:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE polls NodePort 10.245.197.189 <none> 8000:32654/TCP 59s

      Esse resultado mostra o IP interno do cluster do Serviço e o NodePort (32654). Para nos conectar ao serviço, precisamos dos endereços IP externos para nossos nós de cluster:

      Output

      NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME pool-7no0qd9e0-364fd Ready <none> 27h v1.18.8 10.118.0.5 203.0.113.1 Debian GNU/Linux 10 (buster) 4.19.0-10-cloud-amd64 docker://18.9.9 pool-7no0qd9e0-364fi Ready <none> 27h v1.18.8 10.118.0.4 203.0.113.2 Debian GNU/Linux 10 (buster) 4.19.0-10-cloud-amd64 docker://18.9.9 pool-7no0qd9e0-364fv Ready <none> 27h v1.18.8 10.118.0.3 203.0.113.3 Debian GNU/Linux 10 (buster) 4.19.0-10-cloud-amd64 docker://18.9.9

      Em seu navegador Web, visite seu aplicativo Polls usando um endereço IP externo de qualquer nó e o NodePort. De acordo com o resultado acima, a URL do aplicativo seria: http://203.0.113.1:32654/polls.

      Você deve ver a mesma interface do aplicativo Polls que você acessou localmente no Passo 1:

      Interface do aplicativo Polls

      É possível repetir o mesmo teste usando a rota /admin: http://203.0.113.1:32654/admin. Você deve ver a mesma interface de administrador que antes:

      Página de autenticação de administrador do Polls

      Neste estágio, você já implantou duas réplicas do contêiner do aplicativo Polls do Django usando uma Implantação. Você também criou um ponto de extremidade de rede estável para essas duas réplicas, e o tornou externamente acessível usando um Serviço de NodePort.

      O passo final neste tutorial é proteger o tráfego externo para seu aplicativo usando HTTPS. Para fazer isso, vamos usar o Controlador Ingress ingress-nginx instalado nos pré-requisitos e criar um objeto Ingress para rotear o tráfego externo para o Serviço polls do Kubernetes.

      Passo 8 — Configurando o HTTPS usando o Nginx Ingress e o cert-manager

      Os Ingresses do Kubernetes permitem o roteamento do tráfego externo ao cluster do seu Kubernetes de maneira flexível para os Serviços dentro de seu cluster. Isso é alcançado usando os objetos do Ingress, que definem as regras para rotear o tráfego HTTP e HTTPS para os Serviços do Kubernetes e para os Controladores do Ingress, os quais implementam as regras fazendo o balanceamento da carga do tráfego e o seu roteamento para os Serviços de backend apropriados.

      Nos pré-requisitos, você instalou o Controlador Ingress ingress-nginx e o add-on de automação de certificados TLS cert-manager. Você também definiu a preparação e a produção de ClusterIssuers para seu domínio usando a autoridade de certificação Let’s Encrypt e criou um Ingress para testar a emissão de certificados e a criptografia TLS em dois Serviços de backend fictícios. Antes de continuar com este passo, deve-se excluir o Ingress echo-ingress criado no tutorial pré-requisito:

      • kubectl delete ingress echo-ingress

      Se desejar, também pode excluir os Serviços e Implantações fictícios usando o kubectl delete svc e o kubectl delete deploy, mas isso não é essencial para completar este tutorial.

      Você também deve ter criado um registro de DNS A com your_domain.com apontando para o endereço IP público do balanceador de carga do Ingress. Se estiver usando um balanceador de carga da DigitalOcean, é possível encontrar esse endereço IP na seção Load Balancers do Painel de controle. Se estiver usando a DigitalOcean para gerenciar os registros de DNS do seu domínio, consulte Como gerenciar os registros de DNS para aprender como criar registros A.

      Se estiver usando o Kubernetes da DigitalOcean, também certifique-se de ter implementado a solução descrita no Passo 5 de Como configurar um Nginx Ingress com o Cert-Manager no Kubernetes da DigitalOcean.

      Assim que tiver um registro A apontando para o balanceador de carga do Ingress, crie um Ingress para your_domain.com e o Serviço polls.

      Abra um arquivo chamado polls-ingress.yaml no seu editor favorito:

      Cole o manifesto de Ingress a seguir:

      [polls-ingress.yaml]
      apiVersion: networking.k8s.io/v1beta1
      kind: Ingress
      metadata:
        name: polls-ingress
        annotations:
          kubernetes.io/ingress.class: "nginx"
          cert-manager.io/cluster-issuer: "letsencrypt-staging"
      spec:
        tls:
        - hosts:
          - your_domain.com
          secretName: polls-tls
        rules:
        - host: your_domain.com
          http:
            paths:
            - backend:
                serviceName: polls
                servicePort: 8000
      

      Criamos um objeto Ingress chamado polls-ingress e o anotamos para instruir o plano de controle para usar o Controlador Ingress ingress-nginx e o ClusterIssuer de preparo. Também habilitamos o TLS para your_domain.com e armazenamos o certificado e a chave privada em um segredo chamado polls-tls. Por fim, definimos uma regra para rotear o tráfego para o host your_domain.com para o Serviço polls na porta 8000.

      Quando terminar de editar o arquivo, salve e feche-o.

      Crie o Ingress no seu cluster usando o kubectl apply:

      • kubectl apply -f polls-ingress.yaml

      Output

      ingress.networking.k8s.io/polls-ingress created

      É possível usar o kubectl describe para rastrear o estado do Ingress que acabou de ser criado:

      • kubectl describe ingress polls-ingress

      Output

      Name: polls-ingress Namespace: default Address: workaround.your_domain.com Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>) TLS: polls-tls terminates your_domain.com Rules: Host Path Backends ---- ---- -------- your_domain.com polls:8000 (10.244.0.207:8000,10.244.0.53:8000) Annotations: cert-manager.io/cluster-issuer: letsencrypt-staging kubernetes.io/ingress.class: nginx Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal CREATE 51s nginx-ingress-controller Ingress default/polls-ingress Normal CreateCertificate 51s cert-manager Successfully created Certificate "polls-tls" Normal UPDATE 25s nginx-ingress-controller Ingress default/polls-ingress

      Também é possível executar um describe no certificado polls-tls para confirmar ainda mais se sua criação foi bem-sucedida:

      • kubectl describe certificate polls-tls

      Output

      . . . Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Issuing 3m33s cert-manager Issuing certificate as Secret does not exist Normal Generated 3m32s cert-manager Stored new private key in temporary Secret resource "polls-tls-v9lv9" Normal Requested 3m32s cert-manager Created new CertificateRequest resource "polls-tls-drx9c" Normal Issuing 2m58s cert-manager The certificate has been successfully issued

      Isso confirma que o certificado TLS foi emitido com sucesso e a criptografia do HTTPS agora está ativa para your_domain.com.

      Como usamos o ClusterIssuer de preparo, a maior parte dos navegadores Web não irá confiar no certificado falso do Let’s Encrypt que ele emitiu, de forma que navegar até your_domain.com irá resultar em uma página de erro.

      Para enviar um pedido de teste, vamos usar o wget a partir da linha de comando:

      • wget -O - http://your_domain.com/polls

      Output

      . . . ERROR: cannot verify your_domain.com's certificate, issued by ‘CN=Fake LE Intermediate X1’: Unable to locally verify the issuer's authority. To connect to your_domain.com insecurely, use `--no-check-certificate'.

      Vamos usar o sinalizador sugerido --no-check-certificate para ignorar a validação de certificados:

      • wget --no-check-certificate -q -O - http://your_domain.com/polls

      Output

      <link rel="stylesheet" type="text/css" href="https://your_space.nyc3.digitaloceanspaces.com/django-polls/static/polls/style.css"> <p>No polls are available.</p>

      Esse resultado mostra o HTML para a página de interface de /polls, o que também confirma que a folha de estilos está sendo exibida a partir do armazenamento de objetos.

      Agora que você testou com sucesso a emissão de certificados usando o ClusterIssuer de preparo, modifique o Ingress para usar o ClusterIssuer de produção.

      Abra o polls-ingress.yaml para editar mais uma vez:

      Modifique a anotação do cluster-issuer:

      [polls-ingress.yaml]
      apiVersion: networking.k8s.io/v1beta1
      kind: Ingress
      metadata:
        name: polls-ingress
        annotations:
          kubernetes.io/ingress.class: "nginx"
          cert-manager.io/cluster-issuer: "letsencrypt-prod"
      spec:
        tls:
        - hosts:
          - your_domain.com
          secretName: polls-tls
        rules:
        - host: your_domain.com
          http:
            paths:
            - backend:
                serviceName: polls
                servicePort: 8000
      

      Quando terminar, salve e feche o arquivo. Atualize o Ingress usando o kubectl apply:

      • kubectl apply -f polls-ingress.yaml

      Output

      ingress.networking.k8s.io/polls-ingress configured

      É possível usar o kubectl describe certificate polls-tls e o kubectl describe ingress polls-ingress para rastrear o status da emissão de certificados:

      • kubectl describe ingress polls-ingress

      Output

      . . . Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal CREATE 23m nginx-ingress-controller Ingress default/polls-ingress Normal CreateCertificate 23m cert-manager Successfully created Certificate "polls-tls" Normal UPDATE 76s (x2 over 22m) nginx-ingress-controller Ingress default/polls-ingress Normal UpdateCertificate 76s cert-manager Successfully updated Certificate "polls-tls"

      O resultado acima confirma que o novo certificado de produção foi emitido com sucesso e armazenado no Secredo polls-tls.

      Navegue até your_domain.com/polls no seu navegador Web para confirmar se a criptografia do HTTPS está habilitada e tudo está funcionando como esperado. Você deve ver a interface do aplicativo Polls:

      Interface do aplicativo Polls

      Verifique se a criptografia do HTTPS está ativa no seu navegador Web. Se estiver usando o Google Chrome, chegar na página acima sem erros confirma que tudo está funcionando corretamente. Além disso, você deve ver um cadeado na barra de URL. Clicar no cadeado permitirá verificar os detalhes do certificado do Let’s Encrypt.

      Como uma tarefa de limpeza final, você pode alterar opcionalmente o tipo de Serviço polls do NodePort para o tipo exclusivamente interno ClusterIP.

      Modifique o polls-svc.yaml usando seu editor:

      Altere o type de NodePort para ClusterIP:

      polls-svc.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: polls
        labels:
          app: polls
      spec:
        type: ClusterIP
        selector:
          app: polls
        ports:
          - port: 8000
            targetPort: 8000
      

      Quando terminar de editar o arquivo, salve e feche-o.

      Implemente as alterações usando o kubectl apply:

      • kubectl apply -f polls-svc.yaml --force

      Output

      service/polls configured

      Confirme se seu Serviço foi modificado usando o kubectl get svc:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE polls ClusterIP 10.245.203.186 <none> 8000/TCP 22s

      Esse resultado mostra que o tipo de Serviço é agora ClusterIP. A única maneira de acessá-lo é através do seu domínio e do Ingress criados neste passo.

      Conclusão

      Neste tutorial, você implantou um aplicativo Django dimensionável e seguro via HTTPS em um cluster do Kubernetes. O conteúdo estático é servido diretamente do armazenamento de objetos, e o número de Pods em execução pode ser aumentado ou reduzido rapidamente usando o campo replicas no manifesto de Implantação polls-app.

      Se estiver usando um espaço da DigitalOcean, também é possível habilitar a entrega de ativos estáticos através de uma rede de entrega de conteúdo e criar um subdomínio personalizado para seu espaço. Por favor, consulte Habilitando o CDN de Como configurar um aplicativo Django dimensionável com os bancos de dados e espaços gerenciados da DigitalOcean para aprender mais.

      Para revisar o resto da série, visite nossa página da série De contêineres ao Kubernetes com o Django.



      Source link

      Como implantar o Laravel 7 e o MySQL no Kubernetes usando o Helm


      O autor selecionou a Diversity in Tech Fund​​​​​ para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O Laravel é um dos frameworks de aplicação PHP de código aberto mais populares atualmente. Ele é comumente implantado com um banco de dados MySQL, mas pode ser configurado para usar uma variedade de opções de armazenamento de dados de backend. O Laravel se orgulha de tirar proveito de muitos dos recursos modernos do PHP e do extenso ecossistema de pacotes.

      O Kubernetes é uma plataforma de orquestração de contêiner que pode ser hospedada em clusters Kubernetes da DigitalOcean para retirar grande parte do trabalho de administração da instalação e operação de contêineres em produção. O Helm é um gerenciador de pacotes do Kubernetes que facilita a configuração e instalação de serviços e pods no Kubernetes.

      Neste guia, você irá criar uma aplicação Laravel PHP, compilar sua aplicação dentro de uma imagem Docker, e implantar essa imagem em um cluster Kubernetes da DigitalOcean usando o LAMP Helm chart. Em seguida, você irá configurar um controlador Ingress para adicionar SSL e um nome de domínio personalizado à sua aplicação. Quando concluída, você terá uma aplicação Laravel funcionando conectada a um banco de dados MySQL que está em execução em um cluster do Kubernetes.

      Pré-requisitos

      • O Docker instalado na máquina a partir da qual você irá acessar seu cluster. Você pode encontrar instruções sobre como fazer a instalação do Docker para a maioria das distribuições Linux aqui ou no site do Docker para outros sistemas operacionais.
      • Uma conta do Docker Hub para armazenar as imagens do Docker que você criará neste tutorial.
      • Um cluster Kubernetes 1.17+ na DigitalOcean com sua conexão configurada como o kubectl padrão. Para aprender como criar um cluster Kubernetes na DigitalOcean, consulte o Kubernetes Quickstart. Para aprender como se conectar ao cluster, consulte How to Connect to a DigitalOcean Kubernetes Cluster.
      • O gerenciador de pacotes Helm 3 instalado em sua máquina local. Complete o primeiro passo e adicione o repositório stable do segundo passo do tutorial How To Install Software on Kubernetes Clusters with the Helm 3 Package Manager.
      • Um nome de domínio totalmente registrado com um registro A disponível. Este tutorial utilizará o your_domain durante todo o processo. Você pode comprar um nome de domínio em Namecheap, obter um gratuitamente em Freenom ou usar o registrado de domínios de sua escolha. No momento, não se preocupe em associar o registro A do seu domínio a um IP. Quando você chegar no Passo 5 e seu controlador Ingress estiver pronto, você irá conectar your_domain ao IP adequado.

      Passo 1 — Criando uma nova aplicação Laravel

      Neste passo, você irá usar o Docker para criar uma nova aplicação Laravel 7, mas você deve ser capaz de seguir o mesmo processo com uma aplicação Laravel existente que usa o MySQL como banco de banco de dados de backend. A nova aplicação que você compilar irá verificar se o Laravel está conectado ao banco de dados e exibirá o nome do banco de dados.

      Primeiro, vá para seu diretório home e crie uma nova aplicação Laravel usando um contêiner Docker composer:

      • cd ~
      • docker run --rm -v $(pwd):/app composer create-project --prefer-dist laravel/laravel laravel-kubernetes

      Depois que o contêiner estiver pronto e todos os pacotes do Composer estiverem instalados, você deve ver uma nova instalação do Laravel em seu diretório atual chamada laravel-kubernetes/. Navegue até essa pasta:

      Você executará o resto dos comandos deste tutorial a partir daqui.

      O objetivo desta aplicação é testar a conexão do seu banco de dados e exibir seu nome no seu navegador. Para testar a conexão do banco de dados, abra o arquivo ./resources/views/welcome.blade.php em um editor de texto:

      • nano ./resources/views/welcome.blade.php

      Encontre a seção <div class="links">...</div> e substitua seu conteúdo pelo seguinte:

      ./resources/views/welcome.blade.php

      ...
      <div class="links">
         <strong>Database Connected: </strong>
          @php
              try {
                  DB::connection()->getPDO();
                  echo DB::connection()->getDatabaseName();
                  } catch (Exception $e) {
                  echo 'None';
              }
          @endphp
      </div>
      ...
      

      Salve e feche o arquivo.

      Essa é toda a personalização que você precisará fazer na aplicação Laravel padrão para este tutorial. Uma vez concluído, este breve trecho de PHP irá testar sua conexão com o banco de dados e exibirá o nome do banco de dados na tela de splash do Laravel em seu navegador Web.

      No próximo passo, você irá usar o Docker para compilar uma imagem contendo esta aplicação Laravel e o Docker Compose para testar se ele funciona localmente e se conecta a um banco de dados MySQL.

      Passo 2 — Conteinerizando sua aplicação Laravel

      Agora que você criou uma nova aplicação Laravel, você precisará compilar seu código dentro de uma imagem Docker e então testar a imagem com o Docker Compose. Embora o objetivo deste tutorial seja implantar sua aplicação em um cluster Kubernetes, o Docker Compose é uma maneira conveniente de testar sua imagem e configuração do Docker localmente antes de executá-la na nuvem. Este loop de feedback rápido pode ser útil para fazer e testar pequenas mudanças.

      Primeiro, usando o nano ou seu editor de texto preferido, crie um arquivo na raiz da sua aplicação Laravel chamado Dockerfile:

      Adicione o conteúdo a seguir: O Docker irá usar este arquivo para compilar seu código em uma imagem:

      ./Dockerfile

      FROM php:7.4-apache
      
      # Install packages
      RUN apt-get update && apt-get install -y 
          git 
          zip 
          curl 
          sudo 
          unzip 
          libicu-dev 
          libbz2-dev 
          libpng-dev 
          libjpeg-dev 
          libmcrypt-dev 
          libreadline-dev 
          libfreetype6-dev 
          g++
      
      # Apache configuration
      ENV APACHE_DOCUMENT_ROOT=/var/www/html/public
      RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/sites-available/*.conf
      RUN sed -ri -e 's!/var/www/!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/apache2.conf /etc/apache2/conf-available/*.conf
      RUN a2enmod rewrite headers
      
      # Common PHP Extensions
      RUN docker-php-ext-install 
          bz2 
          intl 
          iconv 
          bcmath 
          opcache 
          calendar 
          pdo_mysql
      
      # Ensure PHP logs are captured by the container
      ENV LOG_CHANNEL=stderr
      
      # Set a volume mount point for your code
      VOLUME /var/www/html
      
      # Copy code and run composer
      COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
      COPY . /var/www/tmp
      RUN cd /var/www/tmp && composer install --no-dev
      
      # Ensure the entrypoint file can be run
      RUN chmod +x /var/www/tmp/docker-entrypoint.sh
      ENTRYPOINT ["/var/www/tmp/docker-entrypoint.sh"]
      
      # The default apache run command
      CMD ["apache2-foreground"]
      

      Salve e feche o arquivo.

      Este Dockerfile começa com a imagem Docker PHP 7.4 Apache encontrada no Docker Hub, em seguida, instala vários pacotes Linux que são comumente exigidos pelas aplicações Laravel. Em seguida, ele cria arquivos de configuração do Apache e habilita reescritas de cabeçalho. O Dockerfile instala várias extensões PHP comuns e adiciona uma variável de ambiente para garantir que os logs do Laravel sejam transmitidos ao contêiner via stderr. Isso permitirá que você veja os logs do Laravel fazendo um tail dos logs do Docker Compose ou do Kubernetes.

      Finalmente, o Dockerfile copia todo o código em sua aplicação Laravel para /var/www/tmp e instala as dependências do Composer. Em seguida, ele define um ENTRYPOINT, mas você precisará criar esse arquivo, o que faremos a seguir.

      No diretório raiz do seu projeto, crie um novo arquivo chamado docker-entrypoint.sh. Este arquivo será executado quando o seu contêiner for executado localmente ou no cluster Kubernetes, e ele irá copiar seu código de aplicação Laravel a partir do diretório /var/www/tmp para /var/www/html onde o Apache será capaz de apresentá-lo.

      • nano ./docker-entrypoint.sh

      Agora adicione o seguinte script:

      ./docker-entrypoint.sh

      #!/bin/bash
      
      cp -R /var/www/tmp/. /var/www/html/
      chown -R www-data:www-data /var/www/html
      
      exec "$@"
      

      A linha final, exec "$@" instrui o shell a executar qualquer comando que seja passado como um argumento de entrada a seguir. Isso é importante porque você quer que o Docker continue executando o comando Apache run (apache2-foreground) após este script ser executado. Salve e feche o arquivo.

      Em seguida, crie um arquivo .dockerignore no diretório raiz da sua aplicação. Este arquivo irá garantir que quando você compilar sua imagem Docker ela não ficará poluída com pacotes ou arquivos de ambiente que não devem ser copiados para ela:

      ./.dockerignore

      .env
      /vendor
      

      Salve e feche o arquivo.

      O último arquivo que você precisa criar antes que você possa executar sua aplicação localmente usando o Docker Compose é um arquivo docker-compose.yml. No entanto, durante a configuração deste arquivo YAML, você precisará inserir o APP_KEY que o Laravel gerou durante a instalação. Encontre isso abrindo e pesquisando o arquivo . /.env, ou executando os seguintes comandos cat e grep:

      Você verá uma saída como esta:

      Output

      APP_KEY=base64:0EHhVpgg ... UjGE=

      Copie sua chave para sua área de transferência. Certifique-se de incluir o prefixo base64: Agora crie o arquivo docker-compose.yml no diretório raiz da sua aplicação:

      • nano ./docker-compose.yml

      Aqui incluiremos a imagem PHP da sua aplicação Laravel, bem como um contêiner MySQL para executar o seu banco de dados. Adicione o conteúdo a seguir:

      ./docker-compose.yml

      version: '3.5'
      services:
        php:
          image: your_docker_hub_username/laravel-kubernetes:latest
          restart: always
          ports:
            - 8000:80
          environment:
            - APP_KEY="your_laravel_app_key"
            - APP_ENV=local
            - APP_DEBUG=true
            - DB_PORT=3306
            - DB_HOST=mysql
            - DB_DATABASE
            - DB_USERNAME
            - DB_PASSWORD
        mysql:
          image: mysql:5.7
          restart: always
          environment:
            - MYSQL_ROOT_PASSWORD=${DB_ROOT_PASSWORD}
            - MYSQL_DATABASE=${DB_DATABASE}
            - MYSQL_USER=${DB_USERNAME}
            - MYSQL_PASSWORD=${DB_PASSWORD}
      

      Use a variável APP_KEY que você copiou para sua área de transferência para a variável your_laravel_app_key e use seu nome de usuário do Docker Hub para a variável your_docker_hub_username. Salve e feche o arquivo.

      Você irá criar a primeira imagem localmente usando o docker build. A segunda imagem é a imagem Docker oficial do MySQL disponível no Docker Hub. Ambos exigem várias variáveis de ambiente, que você irá incluir quando você executar os contêineres.

      Para compilar a imagem Docker que contém sua aplicação Laravel, execute o seguinte comando. Certifique-se de substituir your_docker_hub_username pelo nome de usuário ou nome de sua equipe no Docker Hub onde essa imagem será armazenada:

      • docker build -t your_docker_hub_username/laravel-kubernetes:latest .

      Em seguida, você pode executar os dois contêineres com o Docker Compose com as credenciais de banco de dados necessárias:

      • DB_ROOT_PASSWORD=rootpassword DB_DATABASE=local_db DB_USERNAME=admin DB_PASSWORD=password docker-compose up -d

      As quatro variáveis de ambiente usadas aqui (DB_ROOT_PASSWORD, DB_DATABASE, DB_USERNAME, DB_PASSWORD) podem ser modificadas se você quiser, mas uma vez que você está testando sua aplicação somente localmente, você não precisa se preocupar em protegê-las ainda.

      Pode demorar até 30 segundos para que seu banco de dados MySQL inicialize e os contêineres estejam prontos. Depois que eles etiverem prontos, você pode visualizar sua aplicação Laravel em sua máquina em localhost:8000.

      The Laravel application running locally using Docker Compose

      Sua aplicação PHP irá se conectar ao seu banco de dados MySQL. Após uma conexão bem-sucedida, o texto “Database Connected: local_db” irá aparecer sob o logotipo do Laravel.

      Agora que você testou sua imagem Docker localmente usando o Docker Compose, você pode desligar os contêineres executando docker-compose down:

      Na próxima seção, você irá enviar sua imagem Docker para o Docker Hub para que seu Helm chart possa utilizá-la para implantar a aplicação no cluster Kubernetes.

      Passo 3 — Enviando sua imagem Docker para o Docker Hub

      O LAMP Helm Chart que você irá usar para implantar seu código no Kubernetes requer que seu código esteja disponível em um registro de contêiner. Embora você possa enviar sua imagem para um registro privado ou auto-hospedado, para os propósitos deste tutorial, você irá usar um registro Docker gratuito e disponível publicamente no Docker Hub.

      Acesse sua conta no Docker Hub usando seu navegador Web e então crie um novo repositório chamado laravel-kubernetes.

      Creating a new repository on Docker Hub

      Em seguida, se você não tiver conectado ao Docker Hub a partir de sua máquina local, você precisará fazer login no Docker Hub. Você pode fazer isso através da linha de comando:

      • docker login -u your_docker_hub_username

      Digite suas credenciais de login quando solicitado. Isso normalmente só precisa ser feito uma vez por máquina, pois o Docker irá salvar suas credenciais em ~/.docker/config.json em seu diretório home.

      Finalmente, envie sua imagem para o Docker Hub:

      • docker push your_docker_hub_username/laravel-kubernetes:latest

      Pode demorar alguns minutos para fazer upload da sua aplicação dependendo da velocidade da sua conexão, mas uma vez que o Docker tiver feito, você verá um digest hash final e o tamanho da sua imagem no terminal. Eles se parecerão com isso:

      Output

      latest: digest: sha256:df4bdeda91484c8c26a989b13b8f27ab14d93ab2e676e3c396714cb3811c4086 size: 4918

      Agora que sua aplicação Laravel está conteinerizada e você enviou uma imagem para o Docker Hub, use a imagem em uma implantação do Helm Chart ou do Kubernetes. No próximo passo, você irá definir valores personalizados com base no LAMP Helm Chart e implantá-los em seu cluster Kubernetes.na DigitalOcean.

      O Helm fornece uma variedade de Charts para ajudá-lo a configurar aplicações Kubernetes usando combinações predefinidas de ferramentas. Embora você possa escrever seus próprios arquivos de serviço do Kubernetes para realizar uma implantação semelhante, você verá nesta seção que usar um Helm Chart irá exigir muito menos configuração.

      Primeiro, você precisará de um diretório para armazenar todos os seus arquivos de configuração do Helm. Crie um novo diretório na raiz do seu projeto Laravel chamado helm/:

      Dentro do diretório helm/, você irá criar dois novos arquivos: values.yml e secrets.yml. Primeiro, crie e abra values.yml:

      O arquivo values.yml irá incluir opções de configuração não secretas que irão substituir os valores padrão no LAMP Helm chart. Adicione as seguintes configurações, certificando-se de substituir your_docker_hub_username pelo seu próprio nome de usuário:

      ./helm/values.yml

      php:
        repository: "your_docker_hub_username/laravel-kubernetes"
        tag: "latest"
        fpmEnabled: false
        envVars:
          - name: APP_ENV
            value: production
          - name: APP_DEBUG
            value: false
          - name: DB_PORT
            value: 3306
          - name: DB_HOST
            value: localhost
      

      Salve e feche o arquivo.

      Agora crie um arquivo secrets.yml:

      secrets.yml não será verificado no controle de versão. Ele irá conter informações de configuração confidenciais como a senha do seu banco de dados e a chave da aplicação Laravel. Adicione as seguintes configurações, ajustando-as conforme necessário para corresponder às suas credenciais:

      ./helm/secrets.yml

      mysql:
        rootPassword: "your_database_root_password"
        user: your_database_user
        password: "your_database_password"
        database: your_database_name
      
      php:
        envVars:
          - name: APP_KEY
            value: "your_laravel_app_key"
          - name: DB_DATABASE
            value: your_database_name
          - name: DB_USERNAME
            value: your_database_user
          - name: DB_PASSWORD
            value: "your_database_password"
      

      Certifique-se de usar combinações de nome de usuário e senha fortes para seu banco de dados de produção, e use a mesma your_laravel_app_key como acima, ou abra uma nova janela de terminal e gere uma nova chave executando o seguinte comando. Você pode então copiar o novo valor que o Laravel definir em seu arquivo .env:

      • docker run --rm -v $(pwd):/app php:cli php /app/artisan key:generate

      Salve e feche o arquivo secrets.yml.

      Em seguida, para evitar que seu arquivo secrets.yml seja incorporado na imagem Docker ou salvo no controle de versão, certifique-se de adicionar a seguinte linha a ambos os arquivos .dockerignore e .gitignore. Abra e acrescente /helm/secrets.yml a cada arquivo, ou execute o seguinte comando para adicionar ambos:

      • echo '/helm/secrets.yml' >> ./.dockerignore && echo '/helm/secrets.yml' >> ./.gitignore

      Agora que você criou arquivos de configuração do Helm para sua aplicação e a imagem Docker, você pode instalar este Helm chart como uma nova versão em seu cluster Kubernetes. Instale seu chart a partir do diretório raiz da sua aplicação:

      • helm install laravel-kubernetes -f helm/values.yml -f helm/secrets.yml stable/lamp

      Você verá uma saída como esta:

      Output

      NAME: laravel-kubernetes LAST DEPLOYED: Mon May 18 13:21:20 2020 NAMESPACE: default STATUS: deployed REVISION: 1

      Sua aplicação irá demorar um ou dois minutos para se tornar disponível, mas você pode executar este comando para monitorar os serviços Kubernetes em seu cluster:

      Procure pelo nome da sua aplicação:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) laravel-kubernetes-lamp LoadBalancer your_cluster_ip your_external_ip 80:32175/TCP,3306:32243/TCP

      Quando seu novo serviço laravel-kubernetes-lamp exibir um endereço IP sob EXTERNAL-IP, você pode visitar your_external_ip para ver a aplicação em execução no seu cluster Kubernetes. Sua aplicação irá se conectar ao seu banco de dados e você verá o nome do banco de dados abaixo do logotipo do Laravel, como você fez ao executar sua aplicação localmente no Docker Compose.

      The Laravel application running on Kubernetes using the LAMP Helm chart

      Executar uma aplicação Web em um endereço IP desprotegido pode não ser um problema para uma prova de conceito, mas seu site não está pronto para a produção sem um certificado SSL e um nome de domínio personalizado. Antes de configurar isso no próximo passo, desinstale seu release através da linha de comando:

      • helm delete laravel-kubernetes

      No próximo passo, você irá expandir esta primeira configuração do Helm para adicionar um controlador Ingress, um certificado SSL e um domínio personalizado à sua aplicação Laravel.

      Passo 5 — Adicionando um controlador Ingress e SSL ao seu cluster Kubernetes

      No Kubernetes, um controlador Ingress é responsável por expor os serviços da sua aplicação à internet. No passo anterior, o LAMP Helm chart criou um balanceador de carga da DigitalOcean e expôs sua aplicação diretamente através do endereço IP do balanceador.

      Você pode terminar o SSL e seu nome de domínio diretamente no balanceador de carga, mas como você está trabalhando no Kubernetes, pode ser mais conveniente gerenciar tudo isso no mesmo lugar. Para saber muito mais sobre controladores Ingress e detalhes sobre os seguintes passos, leia o tutorial How To Set Up an Nginx Ingress on DigitalOcean Kubernetes Using Helm.

      O LAMP Helm chart inclui uma opção de configuração para suportar o Ingress. Abra seu arquivo helm/values.yml:

      Agora, adicione as linhas a seguir:

      ./helm/values.yml

      ...
      # Use Ingress Controller
      service:
        type: ClusterIP
        HTTPPort: 80
      ingress:
        enabled: true
        domain: your_domain
      

      Isso instrui sua implantação a não instalar um balanceador de carga e, em vez disso, expor a aplicação à porta 80 do cluster Kubernetes, onde o controlador Ingress irá expô-la à internet. Salve e feche o arquivo values.yml.

      Agora, execute o comando helm install que você executou anteriormente para que sua aplicação Laravel seja executada novamente. Certifique-se de executar o comando a partir do diretório raiz da sua aplicação:

      • helm install laravel-kubernetes -f helm/values.yml -f helm/secrets.yml stable/lamp

      Em seguida, instale o controlador nginx-ingress em seu cluster Kubernetes usando o controlador Ingress Nginx mantido pelo Kubernetes:

      • helm install nginx-ingress stable/nginx-ingress --set controller.publishService.enabled=true

      Depois da instalação, você verá uma saída como esta:

      Output

      NAME: nginx-ingress LAST DEPLOYED: Mon May 18 13:28:34 2020 NAMESPACE: default STATUS: deployed REVISION: 1

      Você também precisa de um recurso ou Resource Ingress para expor sua implantação da aplicação Laravel. Crie um novo arquivo no diretório raiz da sua aplicação chamado ingress.yml:

      Este arquivo define o host da sua aplicação, o gerenciador de certificados SSL e o serviço de backend e o nome da porta. Adicione as seguintes configurações, substituindo your_domain pelo domínio da sua escolha:

      ./ingress.yml

      apiVersion: networking.k8s.io/v1beta1
      kind: Ingress
      metadata:
        name: laravel-kubernetes-ingress
        annotations:
          kubernetes.io/ingress.class: nginx
          cert-manager.io/cluster-issuer: letsencrypt-prod
      spec:
        tls:
          - hosts:
              - your_domain
            secretName: laravel-kubernetes-tls
        rules:
          - host: your_domain
            http:
              paths:
                - backend:
                    serviceName: laravel-kubernetes-lamp
                    servicePort: 80
      

      Salve e feche o arquivo.

      Em seguida, você deve instalar o Cert-Manager e criar um emissor que lhe permitirá criar certificados SSL de produção usando o Let’s Encrypt. O Cert-Manager requer Definições de Recursos Personalizadas que você pode aplicar a partir do repositório Cert-Manager usando a linha de comando:

      • kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.0/cert-manager.crds.yaml

      Isto irá criar uma série de recursos do Kubernetes que serão exibidos na linha de comando:

      Output

      customresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io created customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io created customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io created customresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io created customresourcedefinition.apiextensions.k8s.io/issuers.cert-manager.io created customresourcedefinition.apiextensions.k8s.io/orders.acme.cert-manager.io create

      O Cert-Manager também requer um namespace para isolá-lo em seu cluster Kubernetes:

      • kubectl create namespace cert-manager

      Você verá esta saída:

      Output

      namespace/cert-manager created

      Como o Cert-Manager do Jetstack não é um dos charts mantidos pelo Kubernetes, você precisará adicionar o repositório Helm do Jetstack também. Execute o seguinte comando para torná-lo disponível no Helm:

      • helm repo add jetstack https://charts.jetstack.io

      Uma adição bem sucedida irá exibir o seguinte:

      Output

      "jetstack" has been added to your repositories

      Agora você está pronto para instalar o Cert-Manager no namespace cert-manager em seu cluster Kubernetes:

      • helm install cert-manager --version v0.15.0 --namespace cert-manager jetstack/cert-manager

      Quando terminar, você verá um resumo da implantação como este:

      Output

      NAME: cert-manager LAST DEPLOYED: Mon May 18 13:32:08 2020 NAMESPACE: cert-manager STATUS: deployed REVISION: 1

      O último arquivo que você precisará adicionar ao diretório raiz da sua aplicação Laravel é um arquivo de configuração do Kubernetes production_issuer.yml. Crie o arquivo:

      • nano ./production_issuer.yml

      Agora, adicione o seguinte:

      apiVersion: cert-manager.io/v1alpha2
      kind: ClusterIssuer
      metadata:
        name: letsencrypt-prod
      spec:
        acme:
          # Email address used for ACME registration
          email: your_email_address
          server: https://acme-v02.api.letsencrypt.org/directory
          privateKeySecretRef:
            # Name of a secret used to store the ACME account private key
            name: letsencrypt-prod-private-key
          # Add a single challenge solver, HTTP01 using nginx
          solvers:
            - http01:
                ingress:
                  class: nginx
      

      Salve e feche o arquivo.

      O Let’s Encrypt irá enviar para your_email_address quaisquer avisos importantes e avisos de expiração, então certifique-se de adicionar um endereço que você irá verificar regularmente. Salve este arquivo e crie um novo recurso tanto para o seu recurso Ingress quanto para o emissor de produção em seu cluster Kubernetes:

      • kubectl create -f ingress.yml
      • kubectl create -f production_issuer.yml

      Finalmente, atualize os registros DNS do seu nome de domínio para apontar um registro A para o endereço IP do seu balanceador de carga. Para encontrar o endereço IP para seu controlador Ingress digite:

      • kubectl get service nginx-ingress-controller

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-ingress-controller LoadBalancer your_cluster_ip your_external_ip 80:30187/TCP,443:31468/TCP 6m10s

      Use o endereço your_external_ip como o endereço IP para seu registro A no DNS. O processo para atualizar seus registros DNS varia dependendo do local onde você gerencia seus nomes de domínio e hospedagem DNS, mas se você estiver usando a DigitalOcean você pode buscar referência em nosso guia How to Manage DNS Records.

      Depois que seus registros de DNS atualizarem e seu certificado SSL for gerado, sua aplicação estará disponível em your_domain e o SSL estará habilitado.

      The Laravel application with SSL termination and a custom domain name

      Embora sua aplicação PHP e seu banco de dados já estejam conectados, você ainda precisará executar as migrações de banco de dados. No último passo, você verá como executar comandos Artisan em seu pod Kubernetes para realizar migrações de banco de dados e outras tarefas comuns de manutenção.

      Passo 6 — Executando comandos remotos

      Embora sua aplicação Laravel esteja executando e esteja conectada ao banco de dados MySQL no Kubernetes, há várias operações comuns que você deve executar em uma nova instalação do Laravel. Uma tarefa comum que você deve realizar são as migrações de banco de dados.

      Antes que você possa executar um comando Artisan em sua aplicação Laravel, você precisa saber o nome do pod que está executando seu contêiner da aplicação Laravel. Usando a linha de comando, você pode visualizar todos os pods em seu cluster Kubernetes:

      Você verá uma saída como esta:

      Output

      NAME READY STATUS RESTARTS AGE laravel-kubernetes-lamp-77fb989b46-wczgb 2/2 Running 0 16m

      Selecione o pod para sua implantação laravel-kubernetes-lamp-.... Certifique-se de usar o nome em sua saída e não o que está listado acima. Agora, você pode executar o kubectl exec nele. Por exemplo, execute uma migração de banco de dados usando o comando artisan migrate. Você irá adicionar a flag --force porque você está executando o pod em produção:

      • kubectl exec laravel-kubernetes-lamp-77fb989b46-wczgb -- php artisan migrate --force

      Este comando irá produzir uma saída:

      Output

      Migration table created successfully. Migrating: 2014_10_12_000000_create_users_table Migrated: 2014_10_12_000000_create_users_table (0.16 seconds) Migrating: 2019_08_19_000000_create_failed_jobs_table Migrated: 2019_08_19_000000_create_failed_jobs_table (0.05 seconds)

      Agora, você implantou com sucesso o Laravel 7 e o MySQL no Kubernetes e realizou uma tarefa essencial de manutenção de banco de dados.

      Conclusão

      Neste tutorial, você aprendeu como conteinerizar uma aplicação PHP Laravel, conectar-se a um banco de dados MySQL, enviar uma imagem Docker contendo o seu código para o Docker Hub, e então usar um Helm chart para implantar essa imagem em um cluster Kubernetes da DigitalOcean. Finalmente, você adicionou SSL e um nome de domínio personalizado e aprendeu como executar ferramentas de linha de comando em seus pods em execução.

      O Kubernetes e o Helm lhe oferecem uma série de vantagens em relação à tradicional hospedagem de pilhas LAMP: escalabilidade, a capacidade de alternar serviços sem precisar fazer login diretamente no seu servidor, ferramentas para realizar atualizações contínuas e controlar seu ambiente de hospedagem. Dito isso, a complexidade de inicialmente conteinerizar e configurar sua aplicação torna a barreira para começar bastante alta. Com este guia como ponto de partida, implantar o Laravel no Kubernetes torna-se mais acessível. A partir daqui você pode considerar aprender mais sobre o poder do Laravel ou adicionar ferramentas de monitoramento ao Kubernetes como o Linkerd, que você pode instalar manualmente com nosso guia ou com um droplet 1-Click da DigitalOcean.



      Source link

      Como implantar e gerenciar seu DNS usando o DNSControl no Debian 10


      O autor selecionou a Electronic Frontier Foundation, Inc para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O DNSControl é uma ferramenta de infraestrutura como código que permite a implantação e gerenciamento de suas zonas DNS (Sistema de Nomes de Domínios, do inglês Domain Name System) usando princípios de desenvolvimento de software padrão, incluindo o controle, teste e implantação automática de versão. O DNSControl foi criado pelo Stack Exchange e foi escrito em Go.

      O DNSControl elimina muitas das armadilhas do gerenciamento manual de DNS, considerando que os arquivos da zona ficam armazenados em um formato programável. Isso permite que você implante zonas para vários provedores de DNS simultaneamente, identifique erros de sintaxe e envie a configuração DNS automaticamente, reduzindo o risco de erro humano. Outro uso comum do DNSControl é a migração rápida de seu DNS para um provedor diferente; por exemplo, no caso de um ataque DDoS ou uma interrupção do sistema.

      Neste tutorial, você instalará e configurará o DNSControl, criará uma configuração básica do DNS e começará a implantar registros DNS em um provedor ativo. Como parte deste tutorial, usaremos a DigitalOcean como o provedor DNS do exemplo. Se quiser usar um provedor diferente, a configuração é bastante parecida. Quando terminar, você conseguirá gerenciar e testar sua configuração de DNS em um ambiente seguro e offline e, depois, poderá implantá-lo para a produção.

      Pré-requisitos

      Antes de iniciar este guia, você precisará do seguinte:

      • Um servidor Debian 10 configurado de acordo com as instruções no artigo Configuração Inicial do servidor com o Debian 10, incluindo um usuário não raiz sudo e o firewall habilitado para bloquear portas não essenciais. O your-server-ipv4-address se refere ao endereço IP do servidor onde você estiver hospedando seu site ou domínio. O your-server-ipv6-address se refere ao endereço IPv6 do servidor onde você estiver hospedando seu site ou domínio.
      • Um nome de domínio devidamente registrado com o DNS hospedado por um provedor compatível. Este tutorial usará o your_domain durante todo o processo e a DigitalOcean como a provedora de serviço.
      • Uma chave de API para a DigitalOcean (Token de acesso pessoal), com permissões de leitura e gravação. Para criar uma chave, acesse a página Como criar um Token de acesso pessoal.

      Assim que estiver com tudo pronto, faça login no seu servidor como usuário não raiz para começar.

      Passo 1 — Como instalar o DNSControl

      O DNSControl foi escrito em Go, de modo que você começará este passo instalando o Go em seu servidor e configurando o seu GOPATH.

      O Go está disponível dentro dos repositórios padrão de software do Debian, possibilitando que ele seja instalado com as ferramentas de gerenciamento de pacotes convencionais.

      Também será necessário instalar o Git, pois ele é necessário para permitir que o Go baixe e instale o software DNSControl a partir de seu repositório no GitHub.

      Comece atualizando o índice local de pacotes para refletir quaisquer novas alterações feitas no pacote original (upstream):

      Em seguida, instale os pacotes golang-go e git:

      • sudo apt install golang-go git

      Após confirmar a instalação, a ferramenta apt irá baixar e instalar o Go e o Git, bem como todas as suas respectivas dependências.

      Em seguida, você irá configurar as variáveis de ambiente path necessárias para o Go. Se quiser saber mais sobre isso, leia o tutorial Entendendo o GOPATH. Comece editando o arquivo ~/.profile:

      Adicione as seguintes linhas ao final do seu arquivo:

      ~/.profile

      ...
      export GOPATH="$HOME/go"
      export PATH="$PATH:$GOPATH/bin"
      

      Assim que tiver adicionado essas linhas ao final do arquivo, salve e feche o arquivo. Em seguida, recarregue seu perfil - seja fazendo log-off e fazendo log-in de volta, ou fornecendo o arquivo novamente:

      Agora que você instalou e configurou o Go, instale o DNSControl.

      O comando go get pode ser usado para obter uma cópia do código, compilá-lo automaticamente e instalá-lo dentro do seu diretório Go:

      • go get github.com/StackExchange/dnscontrol

      Assim que terminar, verifique a versão instalada para garantir que tudo está funcionando:

      Sua saída será semelhante à seguinte:

      Output

      dnscontrol 2.9-dev

      Se ver um erro dnscontrol: command not found, verifique novamente sua configuração de caminho do Go.

      Agora que você instalou o DNSControl, você pode criar um diretório de configuração e conectar o DNSControl ao seu provedor de DNS, a fim de permitir que ele faça alterações em seus registros de DNS.

      Passo 2 — Configurando o DNSControl

      Neste passo, você criará os diretórios de configuração necessários para o DNSControl e o conectará ao seu provedor de DNS para que ele possa começar a fazer alterações dinâmicas (em tempo real) nos seus registros do DNS.

      Primeiro, crie um novo diretório no qual você possa armazenar sua configuração do DNSControl e, então, vá para ele:

      • mkdir ~/dnscontrol
      • cd ~/dnscontrol

      Nota: este tutorial se concentrará na configuração inicial do DNSControl; no entanto, para o uso na produção, é recomendável armazenar sua configuração do DNSControl em um sistema de controle de versão (VCS) como o Git. As vantagens de se usar um VCS incluem o controle total de versões, integração com CI/CD para teste, reverter implantações sem interrupções e assim por diante.

      Se quiser usar o DNSControl para escrever arquivos de zona no BIND, crie também o diretório zones:

      Os arquivos de zona do BIND são um método bruto e padronizado para armazenar zonas/registros do DNS em formato de texto simples. Eles foram originalmente usados para o software de servidor de DNS BIND, mas agora são amplamente adotados como o método padrão para armazenar zonas de DNS. Os arquivos de zona no BIND produzidos pelo DNSControl são úteis caso queira importá-los para um servidor DNS personalizado ou auto-hospedado, ou para fins de auditoria.

      No entanto, se quiser usar o DNSControl para forçar alterações do DNS em um provedor gerenciado, o diretório zones não será necessário.

      Em seguida, você precisa configurar o arquivo creds.json, que é o que permitirá que o DNSControl se autentique para seu provedor DNS e faça as alterações. O formato creds.json difere ligeiramente, dependendo do provedor de DNS que você estiver usando. Para encontrar a configuração do seu próprio provedor, consulte a Lista de provedores de serviço na documentação oficial do DNSControl.

      Crie o arquivo creds.json no diretório ~/dnscontrol:

      • cd ~/dnscontrol
      • nano creds.json

      Adicione a configuração do creds.json do exemplo para o seu provedor de DNS ao arquivo. Se estiver usando o DigitalOcean como seu provedor fr DNS, você pode usar o seguinte:

      ~/dnscontrol/creds.json

      {
      "digitalocean": {
        "token": "your-digitalocean-oauth-token"
      }
      }
      

      Esse arquivo diz ao DNSControl com quais provedores de DNS você quer que ele se conecte.

      Você precisará fornecer alguma forma de autenticação para seu provedor de DNS. Normalmente, essa autenticação consiste em uma chave de API ou token do OAuth, mas alguns provedores exigem informações extra, conforme documentado na Lista de provedores de serviço na documentação oficial do DNSControl.

      Aviso: esse token dará acesso à conta do seu provedor de DNS; dessa maneira, você deve protegê-lo, do mesmo modo que faria com uma senha. Além disso, se você estiver usando um sistema de controle de versão, certifique-se de que o arquivo que contém o token seja excluído (por exemplo, usando o .gitignore) ou criptografado de maneira segura.

      Se estiver usando o DigitalOcean como seu provedor de DNS, você pode usar o token do OAuth necessário em suas configurações de conta do DigitalOcean que você gerou como parte dos pré-requisitos.

      Se você tiver vários provedores de DNS — por exemplo, para nomes de domínios múltiplos, ou zonas de DNS delegadas—você pode definir todos eles no mesmo arquivo creds.json.

      Você definiu os diretórios de configuração inicial do DNSControl e configurou o creds.json para permitir que o DNSControl autentique seu provedor de DNS e faça alterações. Em seguida, você criará a configuração para suas zonas de DNS.

      Passo 3 — Criando um arquivo de configuração de DNS

      Neste passo, você criará um arquivo de configuração inicial do DNS, o qual terá os registros de DNS relacionados ao seu nome de domínio ou à zona de DNS delegada.

      O dnsconfig.js é o arquivo principal de configuração de DNS para o DNSControl. Neste arquivo, as zonas de DNS e seus registros correspondentes são definidos usando a sintaxe do JavaScript. Isso é conhecido como DSL, ou Linguagem Específica de Domínio. A página de DSL do JavaScript - na documentação oficial do DNSControl, fornece mais detalhes.

      Para começar, crie o arquivo de configuração do DNS no diretório ~/dnscontrol:

      • cd ~/dnscontrol
      • nano dnsconfig.js

      Então, adicione a seguinte configuração de exemplo ao arquivo:

      ~/dnscontrol/dnsconfig.js

      // Providers:
      
      var REG_NONE = NewRegistrar('none', 'NONE');
      var DNS_DIGITALOCEAN = NewDnsProvider('digitalocean', 'DIGITALOCEAN');
      
      // Domains:
      
      D('your_domain', REG_NONE, DnsProvider(DNS_DIGITALOCEAN),
        A('@', 'your-server-ipv4-address')
      );
      

      Esse arquivo de exemplo define um nome de domínio ou uma zona de DNS em um provedor em particular que, neste caso, é o your_domain, hospedado pelo DigitalOcean. Um registro de exemplo A também é definido para a zona raiz (@), que aponta para o endereço de IPv4 do servidor no qual você está hospedando seu domínio/site.

      Existem três funções principais que constituem um arquivo de configuração básica de DNSControl:

      • NewRegistrar(name, type, metadata): define o registrador de domínios para o seu nome de domínio. O DNSControl pode usar esse registrador para fazer as alterações necessárias, como modificar os servidores de nomes autorizados. Se quiser usar o DNSControl somente para gerenciar suas zonas de DNS, isso geralmente pode ser deixado como NONE.

      • NewDnsProvider(name, type, metadata)​​​: define um provedor de serviços de DNS para seu nome de domínio ou zona delegada. É aqui que o DNSControl irá forçar as alterações do DNS que você fez.

      • D(name, registrar, modifiers): define um nome de domínio ou zona de DNS delegada para o DNSControl gerenciar, além dos registros de DNS presentes na zona.

      Você deve configurar o NewRegistrar(), o NewDnsProvider() e o D(), conforme for o caso, usando a Lista de provedores de serviços da documentação oficial do DNSControl.

      Se você está usando o DigitalOcean como seu provedor de DNS e precisa ter a capacidade de fazer alterações no DNS (e não em servidores de nome autorizados), o exemplo do bloco de código anterior já está correto.

      Assim que terminar, salve e feche o arquivo.

      Neste passo, você definiu um arquivo de configuração de DNS para o DNSControl, com os fornecedores relevantes definidos. Em seguida, você irá preencher o arquivo com alguns registros úteis de DNS.

      Passo 4 — Preenchendo seu arquivo de configuração de DNS

      Na sequência, você pode preencher o arquivo de configuração de DNS com registros de DNS úteis para o seu site ou serviço, usando a sintaxe do DNSControl.

      Ao contrário dos arquivos tradicionais de zona no BIND, nos quais os registros de DNS são escritos em um formato bruto, linha por linha, os registros DNS dentro do DNSControl são definidos como um parâmetro de função (modificador de domínio) para a função D(), como mostrado brevemente no Passo 3.

      Existe um modificador de domínio para cada um dos tipos de registro padrão de DNS, incluindo A, AAAA, MX, TXT, NS, CAA e assim por diante. Na seção de Modificadores de domínios, da documentação sobre o DNSControl, você encontra uma lista completa dos tipos de registro disponíveis.

      Os modificadores de registros individuais também estão disponíveis (modificadores de registro). Atualmente, eles são usados principalmente para definir a vida útil (TTL ou time to live) de registros individuais. Você encontra a lista completa dos modificadores de registros disponíveis na seção de Modificadores de registro da documentação sobre o DNSControl. Os modifiers de registro são opcionais e, na maioria dos casos de uso básico, podem ser deixados de fora.

      A sintaxe para definir registros de DNS varia ligeiramente em relação a cada tipo de registro. Em seguida, temos alguns exemplos dos tipos de registros mais comuns:

      • Registros do tipo A:

        • Objetivo: apontar para um endereço de IPv4.
        • Sintaxe: A('name', 'address', optional record modifiers)​​​
        • Exemplo: A('@', 'your-server-ipv4-address', TTL(30))
      • Registros do tipo AAAA:

        • Objetivo: apontar para um endereço de IPv6.
        • Sintaxe: AAAA('name', 'address', optional record modifiers)
        • Exemplo: AAAA('@', 'your-server-ipv6-address') (modificador de registro deixado de lado para que a vida útil (TTL) padrão seja usada)
      • Registros do tipo CNAME:

        • Objetivo: transformar o seu domínio/subdomínio em alias de outro.
        • Sintaxe: CNAME('name', 'target', optional record modifiers)
        • Exemplo: CNAME('subdomain1', 'example.org.') (note que um ponto final, ., deve ser incluído se houver pontos no valor)
      • Registros do tipo MX:

        • Objetivo: direcionar e-mails para servidores/endereços específicos.
        • Sintaxe: MX('name', 'priority', 'target', optional record modifiers)
        • Exemplo: MX('@', 10, 'mail.example.net') (note que um ponto final, ., deve ser incluído se houver pontos no valor)
      • Registros do tipo TXT:

        • Objetivo: adicionar texto simples arbitrário, frequentemente usado para configurações sem seu próprio tipo de registro dedicado.
        • Sintaxe: TXT('name', 'content', optional record modifiers)
        • Exemplo: TXT('@', 'This is a TXT record. ')​​​
      • Registros do tipo CAA:

        • Objetivo: restringir e informar sobre as Autoridades de Certificação (CAs) que poderão emitir os certificados de TLS para os seus domínios/subdomínios.
        • Sintaxe: CAA('name', 'tag', 'value', optional record modifiers)
        • Exemplo: CAA('@', 'issue', 'letsencrypt.org')

      Para começar a adicionar registros de DNS ao seu domínio ou zona de DNS delegada, edite seu arquivo de configuração de DNS:

      Em seguida, você pode começar a preencher os parâmetros da função D() existente, usando a sintaxe descrita na lista anterior, além da seção de Modificadores de domínios da documentação oficial sobre DNSControl. Uma vírgula (,) deve ser usada entre cada registro.

      A título de referência, este bloco de código contém um exemplo da configuração completa de uma definição básica, inicial do DNS:

      ~/dnscontrol/dnsconfig.js

      ...
      
      D('your_domain', REG_NONE, DnsProvider(DNS_DIGITALOCEAN),
        A('@', 'your-server-ipv4-address'),
        A('www', 'your-server-ipv4-address'),
        A('mail', 'your-server-ipv4-address'),
        AAAA('@', 'your-server-ipv6-address'),
        AAAA('www', 'your-server-ipv6-address'),
        AAAA('mail', 'your-server-ipv6-address'),
        MX('@', 10, 'mail.your_domain.'),
        TXT('@', 'v=spf1 -all'),
        TXT('_dmarc', 'v=DMARC1; p=reject; rua=mailto:abuse@your_domain; aspf=s; adkim=s;')
      );
      

      Assim que tiver completado sua configuração inicial do DNS, salve e feche o arquivo.

      Neste passo, você configurou o arquivo de configuração inicial do DNS, contendo seus registros de DNS. Em seguida, você testará a configuração e a implantará.

      Passo 5 — Testando e implantando sua configuração de DNS

      Neste passo, você executará uma verificação local da sintaxe em sua configuração de DNS e, em seguida, implantará as alterações no servidor/provedor ativo de DNS.

      Primeiro, vá até seu diretório dnscontrol:

      Em seguida, utilize a função preview do DNSControl para verificar a sintaxe do seu arquivo e mostrar quais alterações ele irá fazer (sem realmente fazer as alterações):

      Se a sintaxe do seu arquivo de configuração do DNS estiver correta, o DNSControl mostrará um panorama das alterações que ele irá fazer. Isso deve ser semelhante ao seguinte:

      Output

      ******************** Domain: your_domain ----- Getting nameservers from: digitalocean ----- DNS Provider: digitalocean...8 corrections #1: CREATE A your_domain your-server-ipv4-address ttl=300 #2: CREATE A www.your_domain your-server-ipv4-address ttl=300 #3: CREATE A mail.your_domain your-server-ipv4-address ttl=300 #4: CREATE AAAA your_domain your-server-ipv6-address ttl=300 #5: CREATE TXT _dmarc.your_domain "v=DMARC1; p=reject; rua=mailto:abuse@your_domain; aspf=s; adkim=s;" ttl=300 #6: CREATE AAAA www.your_domain your-server-ipv6-address ttl=300 #7: CREATE AAAA mail.your_domain your-server-ipv6-address ttl=300 #8: CREATE MX your_domain 10 mail.your_domain. ttl=300 ----- Registrar: none...0 corrections Done. 8 corrections.

      Se ver um aviso de erro em sua saída, o DNSControl dará detalhes sobre o que está errado e onde o erro está localizado dentro do seu arquivo.

      Aviso: o próximo comando fará alterações dinâmicas nos seus registros do DNS e possivelmente em outras configurações. Certifique-se de que esteja preparado para isso, incluindo fazendo um um backup da sua configuração de DNS existente, além de garantir que tenha os meios para reverter o processo, se necessário.

      Por fim, você pode enviar as alterações para seu provedor de DNS ativo:

      Você verá uma saída similar à seguinte:

      Output

      ******************** Domain: your_domain ----- Getting nameservers from: digitalocean ----- DNS Provider: digitalocean...8 corrections #1: CREATE TXT _dmarc.your_domain "v=DMARC1; p=reject; rua=mailto:abuse@your_domain; aspf=s; adkim=s;" ttl=300 SUCCESS! #2: CREATE A your_domain your-server-ipv4-address ttl=300 SUCCESS! #3: CREATE AAAA your_domain your-server-ipv6-address ttl=300 SUCCESS! #4: CREATE AAAA www.your_domain your-server-ipv6-address ttl=300 SUCCESS! #5: CREATE AAAA mail.your_domain your-server-ipv6-address ttl=300 SUCCESS! #6: CREATE A www.your_domain your-server-ipv4-address ttl=300 SUCCESS! #7: CREATE A mail.your_domain your-server-ipv4-address ttl=300 SUCCESS! #8: CREATE MX your_domain 10 mail.your_domain. ttl=300 SUCCESS! ----- Registrar: none...0 corrections Done. 8 corrections.

      Agora, se verificar as configurações de DNS do seu domínio no painel de controle do DigitalOcean, verá as alterações.

      Captura de tela do painel de controle do DigitalOcean, que mostra algumas alterações do DNS, feitas pelo DNSControl.

      Também é possível verificar a criação de registros, executando uma consulta de DNS em relação à sua zona de domínio/delegada usando o dig.

      Se não tiver o dig instalado, será necessário instalar o pacote dnsutils:

      • sudo apt install dnsutils

      Assim que instalar o dig, utilize-o para fazer uma pesquisa de DNS em relação ao seu domínio. Você verá que os registros foram atualizados de forma adequada:

      Você verá uma saída que mostra o endereço IP e o registro relevante de DNS da sua zona - que foi implantado usando o DNSControl. Os registros de DNS podem levar algum tempo para se propagarem, assim, talvez seja necessário esperar e executar esse comando novamente.

      Neste passo final, você executou uma verificação da sintaxe local do arquivo de configuração do DNS. Em seguida, implantou-a em seu provedor de DNS ativo e testou se as alterações foram feitas com êxito.

      Conclusão

      Neste artigo, você configurou o DNSControl e implantou uma configuração de DNS em um provedor ativo. Agora, você pode gerenciar e testar suas alterações de configuração do DNS em um ambiente seguro e offline, antes de implantá-las na produção.

      Se quiser explorar mais esse assunto, o DNSControl foi criado para se integrar ao seu pipeline de CI/CD (Integração Contínua/Entrega Contínua), o que lhe permite executar testes em profundidade e ter mais controle sobre sua implantação na produção. Você também pode pesquisar sobre a integração do DNSControl aos seus processos de compilação/implantação de infraestrutura, o que permite implantar servidores e adicioná-los ao DNS de maneira completamente automática.

      Se quiser avançar ainda mais com o DNSControl, os artigos do DigitalOcean, a seguir, apresentam alguns passos subsequentes interessantes para ajudar a integrar o DNSControl aos fluxos de trabalho de gerenciamento de alterações e implantação de infraestrutura:



      Source link