One place for hosting & domains

      Como Construir um Classificador de Machine Learning em Python com Scikit-learn


      Introdução

      Machine learning ou Aprendizado de máquina é um campo de pesquisa em ciência da computação, inteligência artificial, e estatística. O foco do Machine Learning é treinar algoritmos para aprender padrões e fazer previsões a partir de dados. Machine learning é especialmente valioso porque ele nos leva a utilizar computadores para automatizar o processo de tomada de decisões.

      Você encontrará aplicações de Machine learning em todos os lugares. Netflix e Amazon usam machine learning para fazer novas recomendações de produtos. Bancos usam machine learning para detectar atividades fraudulentas em transações de cartões de crédito, e empresas de assistência à saúde estão começando a usar machine learning para monitorar, avaliar e diagnosticar pacientes.

      Neste tutorial vamos implementar um algoritmo simples de machine learning em Python utilizando Scikit-learn, uma ferramenta de machine learning para Python. Usando um banco de dados de informações sobre tumores de câncer de mama, iremos usar um classificador Naive Bayes (NB) que prevê se um tumor é maligno ou benigno.

      No final deste tutorial, você saberá como construir o seu próprio modelo de machine learning em Python.

      Pré-requisitos

      Para completar este tutorial, você precisará de:

      Passo 1 — Importando o Scikit-learn

      Vamos começar instalando o módulo Python Scikit-learn, um das melhores e mais bem documentadas bibliotecas de machine learning para Python.

      Para começar com nosso projeto de codificação, vamos ativar nosso ambiente de programação Python 3. Certifique-se de estar no diretório onde o seu ambiente está localizado, e execute o seguinte comando:

      Com seu ambiente de programação ativado, verifique se o módulo Scikit-learn já está instalado:

      • python -c "import sklearn"

      Se o sklearn estiver instalado, este comando irá completar sem erros. Se ele não estiver instalado, você verá a seguinte mensagem de erro:

      Output

      Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: No module named 'sklearn'

      A mensagem de erro indica que o módulo sklearn não está instalado, então baixe o biblioteca usando o pip:

      • pip install scikit-learn[alldeps]

      Quando a instalação estiver concluída, inicie o Jupyter Notebook:

      No Jupyter, crie um novo Python Notebook chamado ML Tutorial. Na primeira célula do Notebook, importe o módulo sklearn.

      ML Tutorial

      
      import sklearn
      
      

      Seu notebook deve se parecer com a figura a seguir:

      Agora que temos o sklearn importado em nosso notebook, podemos começar a trabalhar com o dataset para o nosso modelo de machine learning.

      Passo 2 — Importando o Dataset do Scikit-learn

      O dataset com o qual estaremos trabalhando neste tutorial é o Breast Cancer Wisconsin Diagnostic Database. O dataset inclui várias informações sobre tumores de câncer de mama, bem como rótulos de classificação como malignos ou benignos. O dataset tem 569 instâncias, ou dados, sobre 569 tumores e inclui informações sobre 30 atributos, ou características, tais como o raio do tumor, textura, suavidade, e área.

      Utilizando este dataset, construiremos um modelo de machine learning para utilizar as informações sobre tumores para prever se um tumor é maligno ou benigno.

      O Scikit-learn vem instalado com vários datasets que podemos carregar no Python, e o dataset que queremos está incluído. Importe e carregue o dataset:

      ML Tutorial

      
      ...
      
      from sklearn.datasets import load_breast_cancer
      
      # Carregar o dataset
      data = load_breast_cancer()
      
      

      A variável data representa um objeto Python que funciona como um dicionário. As chaves importantes do dicionário a considerar são os nomes dos rótulos de classificação (target_names), os rótulos reais (target), os nomes de atributo/característica (feature_names), e os atributos (data).

      Atributos são uma parte crítica de qualquer classificador. Os atributos capturam características importantes sobre a natureza dos dados. Dado o rótulo que estamos tentando prever (tumor maligno versus benigno), os possíveis atributos úteis incluem o tamanho, raio, e a textura do tumor.

      Crie novas variáveis para cada conjunto importante de informações e atribua os dados:

      ML Tutorial

      
      ...
      
      # Organizar nossos dados
      label_names = data['target_names']
      labels = data['target']
      feature_names = data['feature_names']
      features = data['data']
      
      

      Agora temos listas para cada conjunto de informações. Para entender melhor nosso conjunto de dados, vamos dar uma olhada em nossos dados imprimindo nossos rótulos de classe, o primeiro rótulo da instância de dados, nossos nomes de características, e os valores das características para a primeira instância de dados.

      ML Tutorial

      
      ...
      
      # Olhando para os nossos dados
      print(label_names)
      print(labels[0])
      print(feature_names[0])
      print(features[0])
      
      

      Você verá os seguintes resultados se você executar o código:

      Como mostra a imagem, nossos nomes de classes são malignant and benign (maligno e benigno), que são então mapeados para valores binários de 0 e 1, onde 0 representa tumores malignos e 1 representa tumores benignos. Portanto, nossa primeira instância de dados é um tumor maligno cujo raio médio é 1.79900000e+01.

      Agora que temos nossos dados carregados, podemos trabalhar com eles para construir nosso classificador de machine learning.

      Passo 3 — Organizando Dados em Conjuntos

      Para avaliar o desempenho de um classificador, você deve sempre testar o modelo em dados não visualizados. Portanto, antes da construção de um modelo, divida seus dados em duas partes: um conjunto de treinamento e um conjunto de testes.

      Você usa o conjunto de testes para treinar e avaliar o modelo durante o estágio de desenvolvimento. Então você usa o modelo treinado para fazer previsões no conjunto de testes não visualizado. Essa abordagem lhe dá uma noção do desempenho e robustez do modelo.

      Felizmente, o sklearn tem uma função chamada train_test_split(), que divide seus dados nesses conjuntos. Importe a função e em seguida utilize-a para dividir os dados:

      ML Tutorial

      
      ...
      
      from sklearn.model_selection import train_test_split
      
      # Dividir nossos dados
      train, test, train_labels, test_labels = train_test_split(features,
                                                                labels,
                                                                test_size=0.33,
                                                                random_state=42)
      
      

      A função divide aleatoriamente os dados usando o parâmetro test_size. Neste exemplo, agora temos um conjunto de testes (test) que representa 33% do dataset original. Os dados restantes (train) formam então os dados de treinamento. Também temos os respectivos rótulos para ambas as variáveis train/test, ou seja, train_labels e test_labels.

      Agora podemos passar para o treinamento do nosso primeiro modelo.

      Passo 4 — Construindo e Avaliando o Modelo

      Existem muitos modelos para machine learning, e cada modelo tem seus pontos fortes e fracos. Neste tutorial, vamos nos concentrar em um algoritmo simples que geralmente funciona bem em tarefas de classificação binária, a saber Naive Bayes (NB).

      Primeiro, importe o módulo GaussianNB. Em seguida inicialize o modelo com a função GaussianNB(), depois treine o modelo, ajustando-o aos dados usando gnb.fit():

      ML Tutorial

      
      ...
      
      from sklearn.naive_bayes import GaussianNB
      
      # Inicializar nosso classificador
      gnb = GaussianNB()
      
      # Treinar nosso classificador
      model = gnb.fit(train, train_labels)
      
      

      Depois de treinarmos o modelo, podemos usar o modelo treinado para fazer previsões no nosso conjunto de teste, o que fazemos utilizando a função predict(). A função predict() retorna uma matriz de previsões para cada instância de dados no conjunto de testes. Podemos então, imprimir nossas previsões para ter uma ideia do que o modelo determinou.

      Utilize a função predict() com o conjunto test e imprima os resultados:

      ML Tutorial

      
      ...
      
      # Fazer previsões
      preds = gnb.predict(test)
      print(preds)
      
      

      Execute o código e você verá os seguintes resultados:

      Como você vê na saída do Jupyter Notebook, a função predict() retornou uma matriz de 0s e 1s que representa nossos valores previstos para a classe tumor (maligno vs. benigno).

      Agora que temos nossas previsões, vamos avaliar o desempenho do nosso classificador.

      Passo 5 — Avaliando a Precisão do Modelo

      Usando a matriz de rótulos de classe verdadeira, podemos avaliar a precisão dos valores previstos do nosso modelo comparando as duas matrizes (test_labels vs. preds). Utilizaremos a função accuracy_score() do sklearn para determinar a precisão do nosso classificador de machine learning.

      ML Tutorial

      
      ...
      
      from sklearn.metrics import accuracy_score
      
      # Avaliar a precisão
      print(accuracy_score(test_labels, preds))
      
      

      Você verá os seguintes resultados:

      Como você vê na saída, o classificador NB é 94.15% preciso. Isso significa que 94,15 porcento do tempo o classificador é capaz de fazer a previsão correta se o tumor é maligno ou benigno. Esses resultados sugerem que nosso conjunto de características de 30 atributos são bons indicadores da classe do tumor.

      Você construiu com sucesso seu primeiro classificador de machine learning. Vamos reorganizar o código colocando todas as declarações import no topo do Notebook ou script. A versão final do código deve ser algo assim:

      ML Tutorial

      
      from sklearn.datasets import load_breast_cancer
      from sklearn.model_selection import train_test_split
      from sklearn.naive_bayes import GaussianNB
      from sklearn.metrics import accuracy_score
      
      # Carregar o dataset
      data = load_breast_cancer()
      
      # Organizar nossos dados
      label_names = data['target_names']
      labels = data['target']
      feature_names = data['feature_names']
      features = data['data']
      
      # Olhando para os nossos dados
      print(label_names)
      print('Class label = ', labels[0])
      print(feature_names)
      print(features[0])
      
      # Dividir nossos dados
      train, test, train_labels, test_labels = train_test_split(features,
                                                                labels,
                                                                test_size=0.33,
                                                                random_state=42)
      
      # Inicializar nosso classificador
      gnb = GaussianNB()
      
      # Treinar nosso classificador
      model = gnb.fit(train, train_labels)
      
      # Fazer previsões
      preds = gnb.predict(test)
      print(preds)
      
      # Avaliar a precisão
      print(accuracy_score(test_labels, preds))
      
      

      Agora você pode continuar trabalhando com seu código para ver se consegue fazer com que seu classificador tenha um desempenho ainda melhor. Você pode experimentar com diferentes subconjuntos de características ou mesmo tentar algoritmos completamente diferentes. Confira o website do Scikit-learn para mais ideias sobre machine learning.

      Conclusão

      Neste tutorial, você aprendeu como construir um classificador de machine learning em Python. Agora você pode carregar dados, organizar dados, treinar, prever e avaliar classificadores de machine learning em Python usando o Scikit-learn. Os passos deste tutorial devem ajudá-lo a facilitar o processo de trabalhar com seus próprios dados no Python.

      Traduzido Por Fernando Pimenta



      Source link

      Como Construir Imagens Docker e Hospedar um Repositório de Imagens Docker com o GitLab


      Introdução

      A containerização está rapidamente se tornando o método de empacotamento e deploy de aplicações mais aceito nos ambientes de nuvem. A padronização que ele fornece, juntamente com sua eficiência de recursos (quando comparado a máquinas virtuais completas) e flexibilidade, o tornam um grande facilitador da moderna mentalidade DevOps. Muitas estratégias interessantes de deployment, orquestração e monitoramento nativas para nuvem tornam-se possíveis quando suas aplicações e microsserviços são totalmente containerizados.

      Os containers Docker são de longe os tipos mais comuns de container atualmente. Embora os repositórios públicos de imagem do Docker como o Docker Hub estejam repletos de imagens de software opensource containerizado que você pode fazer um docker pull hoje, para código privado você precisará pagar um serviço para construir e armazenar suas imagens, ou executar seu próprio software para fazer isso.

      O GitLab Community Edition é um pacote de software auto-hospedado que fornece hospedagem de repositório Git, acompanhamento de projetos, serviços de CI/CD, e um registro de imagem Docker, entre outros recursos. Neste tutorial vamos utilizar o serviço de integração contínua do GitLab para construir imagens Docker a partir de uma aplicação de exemplo em Node.js. Estas imagens serão então testadas e carregadas para o nosso próprio registro privado do Docker.

      Pré-requisitos

      Antes de começarmos, precisamos configurar um servidor GitLab seguro, e um GitLab CI runner para executar tarefas de integração contínua. As seções abaixo fornecerão links e maiores detalhes.

      Um Servidor Gitlab Protegido com SSL

      Para armazenar nosso código fonte, executar tarefas de CI/CD, e hospedar um registro Docker, precisamos de uma instância do GitLab instalada em um servidor Ubuntu 16.04. Atualmente, o GitLab recomenda um servidor com pelo menos 2 núcleos de CPU e 4GB de RAM. Adicionalmente, iremos proteger o servidor com certificados SSL do Let’s Encrypt. Para fazer isto, precisaremos de um nome de domínio apontando para o servidor.

      Você pode completar esses pré-requisitos com os seguintes tutoriais:

      Um GitLab CI Runner

      O tutorial Como configurar pipelines de integração contínua com o GitLab CI no Ubuntu 16.04 fornecerá uma visão geral do serviço de CI ou integração contínua do GitLab e mostrará como configurar um CI runner para processar jobs. Vamos construir isso em cima da aplicação de demonstração e da infraestrutura do runner criados neste tutorial.

      Passo 1 — Configurando um GitLab CI Runner Privilegiado

      No pré-requisito do tutorial de integração contínua com o GitLab, configuramos um GitLab runner utilizando sudo gitlab-runner register e seu processo de configuração interativo. Este runner é capaz de executar builds e testes de software dentro de containers Docker isolados.

      Entretanto, para se construir imagens Docker, nosso runner precisa de acesso total ao próprio serviço do Docker. A maneira recomendada de se configurar isto é utilizar a imagem docker-in-docker oficial do Docker para executar os jobs. Isto requer conceder ao runner um modo de execução privileged ou privilegiado. Portanto, criaremos um segundo runner com este modo ativado.

      Nota: Conceder ao runner o modo privileged basicamente desativa todas as vantagens de segurança da utilização de containers. Infelizmente, os outros métodos de ativar runners compatíveis com o Docker também carregam implicações de segurança semelhantes. Por favor, veja a documentação oficial do GitLab no Docker Build para aprender mais sobre as diferentes opções de runners e qual é a melhor para a sua situação.

      Como existem implicações de segurança para a utilização de runner privilegiado, vamos criar um runner específico do projeto que aceitará somente jobs de Docker em nosso projeto hello_hapi (Os administradores de GitLab sempre podem adicionar manualmente esse runner a outros projetos posteriormente). A partir da página do nosso projeto hello_hapi, clique em Settings na parte inferior do menu à esquerda, em seguida clique em CI/CD no sub-menu:

      Agora, clique no botão Expand ao lado da seção de configurações de Runners:

      Haverá algumas informações sobre como configurar um Specific Runner, incluindo um token de registro. Tome nota desse token. Quando o utilizamos para registrar um novo runner, o runner será bloqueado apenas para este projeto.

      Estando nesta página, clique no botão Disable shared Runners. Queremos ter certeza de que nossos jobs de Docker sempre executarão em nosso runner privilegiado. Se um runner compartilhado não privilegiado estivesse disponível, o GitLab pode optar por utilizá-lo, o que resultaria em erros de build.

      Faça o login no servidor que possui o seu CI runner atual. Se você não tiver uma máquina já configurada com os runners, volte e complete a seção Installing the GitLab CI Runner Service do tutorial de pré-requisitos antes de continuar.

      Agora, execute o seguinte comando para configurar o runner privilegiado específico do projeto:

      • sudo gitlab-runner register -n
      • --url https://gitlab.example.com/
      • --registration-token seu-token
      • --executor docker
      • --description "docker-builder"
      • --docker-image "docker:latest"
      • --docker-privileged

      Output

      Registering runner... succeeded runner=61SR6BwV Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

      Certifique-se de substituir suas próprias informações. Nós definimos todas as opções do nosso runner na linha de comando em vez de usar os prompts interativos, porque os prompts não nos permitem especificar o modo --docker-privileged.

      Agora o seu runner está configurado, registrado e executando. Para verificar, volte ao seu navegador. Clique no ícone de chave inglesa na barra de menu principal do GitLab, em seguida clique em Runners no menu à esquerda. Seus runners serão listados:

      Agora que temos um runner capaz de criar imagens do Docker, vamos configurar um registro privado do Docker para carregar imagens para ele.

      Passo 2 — Configurando o Registro Docker do GitLab

      Configurar seu próprio registro do Docker permite que você envie e extraia imagens de seu próprio servidor privado, aumentando a segurança e reduzindo as dependências do seu fluxo de trabalho em serviços externos.

      O GitLab irá configurar um registro Docker privado com apenas algumas atualizações de configuração. Primeiro vamos configurar a URL onde o registro irá residir. Depois, iremos (opcionalmente) configurar o registro para usar um serviço de armazenamento de objetos compatível com S3 para armazenar seus dados.

      Faça SSH em seu servidor GitLab, depois abra o arquivo de configuração do GitLab:

      • sudo nano /etc/gitlab/gitlab.rb

      Role para baixo até a seção Container Registry settings. Vamos descomentar a linha registry_external_url e configurá-la para o nosso host GitLab com a porta número 5555:

      /etc/gitlab/gitlab.rb

      
      registry_external_url 'https://gitlab.example.com:5555'
      

      A seguir, adicione as duas linhas seguintes para dizer ao registro onde encontrar nossos certificados Let’s Encrypt:

      /etc/gitlab/gitlab.rb

      
      registry_nginx['ssl_certificate'] = "/etc/letsencrypt/live/gitlab.example.com/fullchain.pem"
      registry_nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/gitlab.example.com/privkey.pem"
      

      Salve e feche o arquivo, depois reconfigure o GitLab:

      • sudo gitlab-ctl reconfigure

      Output

      . . . gitlab Reconfigured!

      Atualize o firewall para pemitir tráfego para a porta do registro:

      Agora mude para outra máquina com o Docker instalado e efetue o login no registro Docker privado. Se você não tiver o Docker no seu computador de desenvolvimento local, você pode usar qualquer servidor configurado para executar seus jobs do GitLab CI, já que ele tem o Docker instalado:

      • docker login gitlab.example.com:5555

      Você será solicitado para inserir o seu nome de usuário e senha. Use suas credenciais do GitLab para efetuar login.

      Output

      Login Succeeded

      Sucesso! O registro está configurado e funcionando. Atualmente, ele armazenará arquivos no sistema de arquivos local do servidor GitLab. Se você quiser usar um serviço de armazenamento de objetos, continue com esta seção. Se não, pule para o Passo 3.

      Para configurar um backend de armazenamento de objetos para o registro, precisamos saber as seguintes informações sobre o nosso serviço de armazenamento de objetos:

      • Access Key

      • Secret Key

      • Region (us-east-1) por exemplo, se estiver usando Amazon S3, ou Region Endpoint se estiver usando um serviço compatível com S3 (https://nyc.digitaloceanspaces.com)

      • Nome do Bucket

      Se você estiver usando o DigitalOcean Spaces, você pode descobrir como configurar um novo Space e obter as informações acima lendo Como Criar um Space e uma Chave de API na DigitalOcean.

      Quando você tiver suas informações sobre o amazenamento de objetos, abra o arquivo de configuração do GitLab:

      • sudo nano /etc/gitlab/gitlab.rb

      Novamente, role até a seção de registro do container. Procure pelo bloco registry['storage'], descomente o bloco e atualize-o para o seguinte, novamente certificando-se de substituir suas próprias informações, quando apropriado:

      /etc/gitlab/gitlab.rb

      
      registry['storage'] = {
        's3' => {
          'accesskey' => 'sua-key',
          'secretkey' => 'seu-secret',
          'bucket' => 'seu-bucket-name',
          'region' => 'nyc3',
          'regionendpoint' => 'https://nyc3.digitaloceanspaces.com'
        }
      }
      

      Se você estiver uando Amazon S3, você precisa apenas da region e não do regionendpoint. Se estiver usando um serviço S3 compatível, como o Spaces, você irá precisar do regionendpoint. Neste caso, region na verdade não configura nada e o valor que você digita não importa, mas ainda precisa estar presente e não em branco.

      Salve e feche o arquivo.

      Nota: Atualmente, há um bug em que o registro será encerrado após trinta segundos se seu bucket de armazenamento de objetos estiver vazio. Para evitar isso, coloque um arquivo no seu bucket antes de executar a próxima etapa. Você poderá removê-lo mais tarde, após o registro ter adicionado seus próprios objetos.

      Se você estiver usando o Spaces da DigitalOcean, você pode arrastar e soltar um arquivo para carregá-lo usando a interface do Painel de Controle.

      Reconfigure o GitLab mais uma vez:

      • sudo gitlab-ctl reconfigure

      Em sua outra máquina Docker, efetue login no registro novamente para ter certeza de que tudo está bem:

      • docker login gitlab.example.com:5555

      Você deve receber uma mensagem de Login Succeeded.

      Agora que temos nosso registro do Docker configurado, vamos atualizar a configuração de CI da nossa aplicação para criar e testar nossa app, e enviar as imagens Docker para o nosso registro privado.

      Passo 3 — Atualizando o gitlab-ci.yaml e Construindo uma Imagem Docker

      Nota: Se você não concluiu o artigo de pré-requisito do GitLab CI você precisará copiar o repositório de exemplo para o seu servidor GitLab. Siga a seção Copying the Example Repository From GitHub para fazer isto.

      Para que possamos fazer o building de nossa app no Docker, precisamos atualizar o arquivo .gitlab-ci.yml. Você pode editar este arquivo diretamente no GitLab clicando na página principal do projeto, e depois no botão Edit. Alternativamente, você poderia clonar o repositório para a sua máquina local, editar o arquivo, e então fazer um git push nele de volta para o GitLab. Isso ficaria assim:

      • git clone git@gitlab.example.com:sammy/hello_hapi.git
      • cd hello_hapi
      • # edit the file w/ your favorite editor
      • git commit -am "updating ci configuration"
      • git push

      Primeiro, exclua tudo no arquivo, depois cole nele a seguinte configuração:

      .gitlab-ci.yml

      
      image: docker:latest
      services:
      - docker:dind
      
      stages:
      - build
      - test
      - release
      
      variables:
        TEST_IMAGE: gitlab.example.com:5555/sammy/hello_hapi:$CI_COMMIT_REF_NAME
        RELEASE_IMAGE: gitlab.example.com:5555/sammy/hello_hapi:latest
      
      before_script:
        - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN gitlab.example.com:5555
      
      build:
        stage: build
        script:
          - docker build --pull -t $TEST_IMAGE .
          - docker push $TEST_IMAGE
      
      test:
        stage: test
        script:
          - docker pull $TEST_IMAGE
          - docker run $TEST_IMAGE npm test
      
      release:
        stage: release
        script:
          - docker pull $TEST_IMAGE
          - docker tag $TEST_IMAGE $RELEASE_IMAGE
          - docker push $RELEASE_IMAGE
        only:
          - master
      

      Certifique-se de atualizar os URLs e nomes de usuários realçados com suas próprias informações e, em seguida, salve com o botão Commit changes no GitLab. Se você está atualizando o arquivo fora do GitLab, confirme as mudanças e faça git push de volta no GitLab.

      Este novo arquivo de configuração diz ao GitLab para usar a imagem mais recente do docker (image: docker:latest) e vinculá-la ao serviço docker-in-docker (docker:dind). Então, ele define os estágios de build, test, e release. O estágio de build cria a imagem do Docker usando o Dockerfile fornecido pelo repositório, em seguida o carrega para o nosso registro de imagens Docker. Se isso for bem sucedido, o estágio test vai baixar a imagem que acabamos de construir e executar o comando npm test dentro dele. Se o estágio test for bem sucedido, o estágio release irá lançar a imagem, irá colocar uma tag como hello_hapi:latest e irá retorná-la ao registro.

      Dependendo do seu fluxo de trabalho, você também pode adicionar mais estágios test, ou mesmo estágios deploy que levam o aplicativo para um ambiente de preparação ou produção.

      A atualização do arquivo de configuração deve ter acionado um novo build. Volte ao projeto hello_hapi no GitLab e clique no indicador de status do CI para o commit:

      Na página resultante, você pode clicar em qualquer um dos estágios para ver seu progresso:

      Eventualmente, todas as etapas devem indicar que eles foram bem sucedidos, mostrando ícones com a marca de verificação em verde. Podemos encontrar as imagens Docker que acabaram de ser construídas clicando no item Registry no menu à esquerda:

      Se você clicar no pequeno ícone "document" ao lado do nome da imagem, ele copiará o comando apropriado docker pull ... para a sua área de transferência. Você pode então baixar e executar sua imagem:

      • docker pull gitlab.example.com:5555/sammy/hello_hapi:latest
      • docker run -it --rm -p 3000:3000 gitlab.example.com:5555/sammy/hello_hapi:latest

      Output

      > hello@1.0.0 start /usr/src/app > node app.js Server running at: http://56fd5df5ddd3:3000

      A imagem foi baixada do registro e iniciada em um container. Mude para o seu navegador e conecte-se ao aplicativo na porta 3000 para testar. Neste caso, estamos executando o container em nossa máquina local, assim podemos acessá-la via localhost na seguinte URL:

      http://localhost:3000/hello/test
      

      Output

      Hello, test!

      Sucesso! Você pode parar o container com CTRL-C. A partir de agora, toda vez que enviarmos um novo código para a ramificação master do nosso repositório, vamos construir e testar automaticamente uma nova imagem hello_hapi: latest.

      Conclusão

      Neste tutorial, configuramos um novo GitLab runner para criar imagens do Docker, criamos um regisro privado do Docker para armazená-las, e atualizamos um app Node.js para ser construído e testado dentro de containers Docker.

      Para aprender mais sobre os vários componentes utilizados nesta configuração, você pode ler a documentação oficial do GitLab CE, GitLab Container Registry, e do Docker.

      Por Brian Boucheron



      Source link

      Como Criar um Cluster Kubernetes 1.11 Usando Kubeadm no Ubuntu 18.04


      O autor escolheu o Free and Open Source Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O Kubernetes é um sistema de orquestração de container em escala. Inicialmente desenvolvido pelo Google baseado em suas experiências executando containers em produção. O Kubernetes é open source e desenvolvido ativamente por uma comunidade em todo o mundo.

      O Kubeadm atomatiza a instalação e a configuração de componentes do Kubernetes tais como o servidor de API, o Controller Manager, e o Kube DNS. Contudo, ele não cria usuários ou lida com a instalação de dependências no nível do sistema operacional e sua configuração. Para essa tarefas preliminares, é possível utilizar uma ferramenta de gerência de configuração como o Ansible ou o SaltStack. A utilização dessas ferramentas torna a criação de clusters adicionais ou a recriação de clusters existentes muito mais simples e menos propensa a erros.

      Neste guia, você vai configurar um cluster Kubernetes a partir do zero utilizando o Ansible e o Kubeadm, e a seguir fazer o deploy de uma aplicação Nginx containerizada nele.

      Objetivos

      Seu cluster irá incluir os seguintes recursos físicos:

      O node master (um node no Kubernetes refere-se a um servidor) é responsável por gerenciar o estado do cluster. Ele roda o Etcd, que armazena dados de cluster entre componentes que fazem o scheduling de cargas de trabalho para nodes worker ou nodes de trabalho.

      Nodes worker são os servidores onde suas cargas de trabalho (i.e. aplicações e serviços containerizados) irão executar. Um worker continuará a executar sua carga de trabalho uma vez que estejam atribuídos a ela, mesmo se o master for desativado quando o scheduling estiver concluído. A capacidade de um cluster pode ser aumentada adicionando workers.

      Após a conclusão desse guia, você terá um cluster pronto para executar aplicações containerizadas, desde que os servidores no cluster tenham recursos suficientes de CPU e RAM para suas aplicações consumirem. Quase todas as aplicações Unix tradicionais, incluindo aplicações web, bancos de dados, daemons, e ferramentas de linha de comando podem ser containerizadas e feitas para rodar no cluster. O cluster em si consumirá cerca de 300-500MB de memória e 10% de CPU em cada node.

      Uma vez que o cluster esteja configurado, você fará o deploy do servidor web Nginx nele para assegurar que ele está executando as cargas de trabalho corretamente.

      Pré-requisitos

      Passo 1 — Configurando o Diretório da Área de Trabalho e o Arquivo de Inventário Ansible

      Nessa seção, você vai criar um diretório em sua máquina local que irá servir como sua área de trabalho. Você configurará o Ansible localmente para que ele possa se comunicar e executar comandos em seus servidores remotos. Depois disso pronto, você irá criar um arquivo hosts contendo informações de inventário tais como os endereços IP de seus servidores e os grupos aos quais cada servidor pertence.

      Dos seus três servidores, um será o master com um IP exibido como master_ip. Os outros dois servidores serão workers e terão os IPs worker_1_ip e worker_2_ip.

      Crie um diretório chamado ~/kube-cluster no diretório home de sua máquina local e faça um cd para dentro dele:

      • mkdir ~/kube-cluster
      • cd ~/kube-cluster

      Esse diretório será sua área de trabalho para o restante desse tutorial e conterá todos os seus playbooks de Ansible. Ele também será o diretório no qual você irá executar todos os comandos locais.

      Crie um arquivo chamado ~/kube-cluster/hosts usando o nano ou o seu editor de textos favorito:

      • nano ~/kube-cluster/hosts

      Adicione o seguinte texto ao arquivo, que irá especificar informações sobre a estrutura lógica do cluster:

      ~/kube-cluster/hosts

      
      [masters]
      master ansible_host=master_ip ansible_user=root
      
      [workers]
      worker1 ansible_host=worker_1_ip ansible_user=root
      worker2 ansible_host=worker_2_ip ansible_user=root
      
      [all:vars]
      ansible_python_interpreter=/usr/bin/python3
      

      Você deve se lembrar de que arquivos de inventário no Ansible são utilizados para especificar informações de servidor tais como endereços IP, usuários remotos, e agrupamentos de servidores para tratar como uma unidade única para a execução de comandos. O ~/kube-cluster/hosts será o seu arquivo de inventário e você adicionou dois grupos Ansible a ele (masters e workers) especificando a estrutura lógica do seu cluster.

      No grupo masters, existe uma entrada de servidor chamada “master” que lista o IP do node master (master_ip) e especifica que o Ansible deve executar comandos remotos como root.

      De maneira similar, no grupo workers, existem duas entradas para os servidores workers (worker_1_ip e worker_2_ip) que também especificam o ansible_user como root.

      A última linha do arquivo diz ao Ansible para utilizar os intepretadores Python dos servidores remotos para suas operações de gerenciamento.

      Salve e feche o arquivo depois de ter adicionado o texto.

      Tendo configurado o inventário do servidor com grupos, vamos passar a instalar dependências no nível do sistema operacional e a criar definições de configuração.

      Passo 2 — Criando um Usuário Não-Root em Todos os Servidores Remotos

      Nesta seção você irá criar um usuário não-root com privilégios sudo em todos os servidores para que você possa fazer SSH manualmente neles como um usuário sem privilégios. Isso pode ser útil se, por exemplo, você gostaria de ver informações do sistema com comandos como top/htop, ver a lista de containers em execução, ou alterar arquivos de configuração de propriedade do root. Estas operações são rotineiramente executadas durante a manutenção de um cluster, e a utilização de um usuário que não seja root para tarefas desse tipo minimiza o risco de modificação ou exclusão de arquivos importantes ou a realização não intencional de operações perigosas.

      Crie um arquivo chamado ~/kube-cluster/initial.yml na área de trabalho:

      • nano ~/kube-cluster/initial.yml

      A seguir, adicione o seguinte play ao arquivo para criar um usuário não-root com privilégios sudo em todos os servidores. Um play no Ansible é uma coleção de passos a serem realizados que visam servidores e grupos específicos. O seguinte play irá criar um usuário sudo não-root:

      ~/kube-cluster/initial.yml

      
      - hosts: all
        become: yes
        tasks:
          - name: create the 'ubuntu' user
            user: name=ubuntu append=yes state=present createhome=yes shell=/bin/bash
      
          - name: allow 'ubuntu' to have passwordless sudo
            lineinfile:
              dest: /etc/sudoers
              line: 'ubuntu ALL=(ALL) NOPASSWD: ALL'
              validate: 'visudo -cf %s'
      
          - name: set up authorized keys for the ubuntu user
            authorized_key: user=ubuntu key="{{item}}"
            with_file:
              - ~/.ssh/id_rsa.pub
      

      Aqui está um detalhamento do que este playbook faz:

      • Cria um usuário não-root ubuntu.

      • Configura o arquivo sudoers para permitir o usuário ubuntu executar comandos sudo sem uma solicitação de senha.

      • Adiciona a chave pública em sua máquina local (normalmente ~/.ssh/id_rsa.pub) para a lista de chaves autorizadas do usuário remoto ubuntu. Isto o permitirá fazer SSH para dentro de cada servidor como usuário ubuntu.

      Salve e feche o arquivo depois que tiver adicionado o texto.

      Em seguida, rode o playbook localmente executando:

      • ansible-playbook -i hosts ~/kube-cluster/initial.yml

      O comando será concluído dentro de dois a cinco minutos. Na conclusão, você verá uma saída semelhante à seguinte:

      Output

      PLAY [all] **** TASK [Gathering Facts] **** ok: [master] ok: [worker1] ok: [worker2] TASK [create the 'ubuntu' user] **** changed: [master] changed: [worker1] changed: [worker2] TASK [allow 'ubuntu' user to have passwordless sudo] **** changed: [master] changed: [worker1] changed: [worker2] TASK [set up authorized keys for the ubuntu user] **** changed: [worker1] => (item=ssh-rsa AAAAB3...) changed: [worker2] => (item=ssh-rsa AAAAB3...) changed: [master] => (item=ssh-rsa AAAAB3...) PLAY RECAP **** master : ok=5 changed=4 unreachable=0 failed=0 worker1 : ok=5 changed=4 unreachable=0 failed=0 worker2 : ok=5 changed=4 unreachable=0 failed=0

      Agora que a configuração preliminar está completa, você pode passar para a instalação de dependências específicas do Kubernetes.

      Step 3 — Instalando as Dependências do Kubernetes

      Nesta seção, você irá instalar os pacotes no nível do sistema operacional necessários pelo Kubernetes com o gerenciador de pacotes do Ubuntu. Esses pacotes são:

      • Docker – um runtime de container. Este é o componente que executa seus containers. Suporte a outros runtimes como o rkt está em desenvolvimento ativo no Kubernetes.

      • kubeadm – uma ferramenta CLI que irá instalar e configurar os vários componentes de um cluster de uma maneira padrão.

      • kubelet – um serviço/programa de sistema que roda em todos os nodes e lida com operações no nível do node.

      • kubectl – uma ferramenta CLI usada para emitir comandos para o cluster através de seu servidor de API.

      Crie um arquivo chamado ~/kube-cluster/kube-dependencies.yml na área de trabalho:

      • nano ~/kube-cluster/kube-dependencies.yml

      Adicione os seguintes plays ao arquivo para instalar esses pacotes em seus servidores:

      ~/kube-cluster/kube-dependencies.yml

      
      - hosts: all
        become: yes
        tasks:
         - name: install Docker
           apt:
             name: docker.io
             state: present
             update_cache: true
      
         - name: install APT Transport HTTPS
           apt:
             name: apt-transport-https
             state: present
      
         - name: add Kubernetes apt-key
           apt_key:
             url: https://packages.cloud.google.com/apt/doc/apt-key.gpg
             state: present
      
         - name: add Kubernetes' APT repository
           apt_repository:
            repo: deb http://apt.kubernetes.io/ kubernetes-xenial main
            state: present
            filename: 'kubernetes'
      
         - name: install kubelet
           apt:
             name: kubelet
             state: present
             update_cache: true
      
         - name: install kubeadm
           apt:
             name: kubeadm
             state: present
      
      - hosts: master
        become: yes
        tasks:
         - name: install kubectl
           apt:
             name: kubectl
             state: present
      

      O primeiro play no playbook faz o seguinte:

      • Instala o Docker, o runtime de container.

      • Instala o apt-transport-https, permitindo que você adicione fontes HTTPS externas à sua lista de fontes do APT.

      • Adiciona a apt-key do repositório APT do Kubernetes para verificação de chave.

      • Adiciona o repositório APT do Kubernetes à lista de fontes do APT dos seus servidores remotos.

      • Instala kubelet e kubeadm.

      O segundo play consiste de uma única tarefa que instala o kubectl no seu node master.

      Salve e feche o arquivo quando você tiver terminado.

      A seguir, rode o playbook executando localmente:

      • ansible-playbook -i hosts ~/kube-cluster/kube-dependencies.yml

      Na conclusão, você verá uma saída semelhante à seguinte:

      Output

      PLAY [all] **** TASK [Gathering Facts] **** ok: [worker1] ok: [worker2] ok: [master] TASK [install Docker] **** changed: [master] changed: [worker1] changed: [worker2] TASK [install APT Transport HTTPS] ***** ok: [master] ok: [worker1] changed: [worker2] TASK [add Kubernetes apt-key] ***** changed: [master] changed: [worker1] changed: [worker2] TASK [add Kubernetes' APT repository] ***** changed: [master] changed: [worker1] changed: [worker2] TASK [install kubelet] ***** changed: [master] changed: [worker1] changed: [worker2] TASK [install kubeadm] ***** changed: [master] changed: [worker1] changed: [worker2] PLAY [master] ***** TASK [Gathering Facts] ***** ok: [master] TASK [install kubectl] ****** ok: [master] PLAY RECAP **** master : ok=9 changed=5 unreachable=0 failed=0 worker1 : ok=7 changed=5 unreachable=0 failed=0 worker2 : ok=7 changed=5 unreachable=0 failed=0

      Após a execução, o Docker, o kubeadm e o kubelet estarão instalados em todos os seus servidores remotos. O kubectl não é um componente obrigatório e somente é necessário para a execução de comandos de cluster. A instalação dele somente no node master faz sentido nesse contexto, uma vez que você irá executar comandos kubectl somente a partir do master. Contudo, observe que os comandos kubectl podem ser executados a partir de quaisquer nodes worker ou a partir de qualquer máquina onde ele possa ser instalado e configurado para apontar para um cluster.

      Todas as dependências de sistema agora estão instaladas. Vamos configurar o node master e inicializar o cluster.

      Passo 4 — Configurando o Node Master

      Nesta seção, você irá configurar o node master. Antes da criação de quaisquer playbooks, contudo, vale a pena cobrir alguns conceitos como Pods e Plugins de Rede do Pod, uma vez que seu cluster incluirá ambos.

      Um pod é uma unidade atômica que executa um ou mais containers. Esses containers compartilham recursos tais como volumes de arquivo e interfaces de rede em comum. Os pods são a unidade básica de scheduling no Kubernetes: todos os containers em um pod têm a garantia de serem executados no mesmo node no qual foi feito o scheduling do pod.

      Cada pod tem seu próprio endereço IP, e um pod em um node deve ser capaz de acessar um pod em outro node utilizando o IP do pod. Os containers em um único node podem se comunicar facilmente através de uma interface local. Contudo, a comunicação entre pods é mais complicada e requer um componente de rede separado que possa encaminhar o tráfego de maneira transparente de um pod em um node para um pod em outro node.

      Essa funcionalidade é fornecida pelos plugins de rede para pods. Para este cluster vamos utilizar o Flannel, uma opção estável e de bom desempenho.

      Crie um playbook Ansible chamado master.yml em sua máquina local:

      • nano ~/kube-cluster/master.yml

      Adicione o seguinte play ao arquivo para inicializar o cluster e instalar o Flannel:

      ~/kube-cluster/master.yml

      
      - hosts: master
        become: yes
        tasks:
          - name: initialize the cluster
            shell: kubeadm init --pod-network-cidr=10.244.0.0/16 >> cluster_initialized.txt
            args:
              chdir: $HOME
              creates: cluster_initialized.txt
      
          - name: create .kube directory
            become: yes
            become_user: ubuntu
            file:
              path: $HOME/.kube
              state: directory
              mode: 0755
      
          - name: copy admin.conf to user's kube config
            copy:
              src: /etc/kubernetes/admin.conf
              dest: /home/ubuntu/.kube/config
              remote_src: yes
              owner: ubuntu
      
          - name: install Pod network
            become: yes
            become_user: ubuntu
            shell: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.9.1/Documentation/kube-flannel.yml >> pod_network_setup.txt
            args:
              chdir: $HOME
              creates: pod_network_setup.txt
      

      Aqui está um detalhamento deste play:

      • A primeira tarefa inicializa o cluster executando kubeadm init. A passagem do argumento --pod-network-cidr=10.244.0.0/16 especifica a sub-rede privada que os IPs do pod serão atribuídos. O Flannel utiliza a sub-rede acima por padrão; estamos dizendo ao kubeadm para utilizar a mesma sub-rede.

      • A segunda tarefa cria um diretório .kube em /home/ubuntu. Este diretório irá manter as informações de configuração tais como os arquivos de chaves do admin, que são requeridas para conectar no cluster, e o endereço da API do cluster.

      • A terceira tarefa copia o arquivo /etc/kubernetes/admin.conf que foi gerado a partir do kubeadm init para o diretório home do seu usuário não-root. Isso irá permitir que você utilize o kubectl para acessar o cluster recém-criado.

      • A última tarefa executa kubectl apply para instalar o Flannel. kubectl apply -f descriptor.[yml|json] é a sintaxe para dizer ao kubectl para criar os objetos descritos no arquivo descriptor.[yml|json]. O arquivo kube-flannel.yml contém as descrições dos objetos requeridos para a configuração do Flannel no cluster.

      Salve e feche o arquivo quando você tiver terminado.

      Rode o playbook localmente executando:

      • ansible-playbook -i hosts ~/kube-cluster/master.yml

      Na conclusão, você verá uma saída semelhante à seguinte:

      Output

      PLAY [master] **** TASK [Gathering Facts] **** ok: [master] TASK [initialize the cluster] **** changed: [master] TASK [create .kube directory] **** changed: [master] TASK [copy admin.conf to user's kube config] ***** changed: [master] TASK [install Pod network] ***** changed: [master] PLAY RECAP **** master : ok=5 changed=4 unreachable=0 failed=0

      Para verificar o status do node master, faça SSH nele com o seguinte comando:

      Uma vez dentro do node master, execute:

      Agora você verá a seguinte saída:

      Output

      NAME STATUS ROLES AGE VERSION master Ready master 1d v1.11.1

      A saída informa que o node master concluiu todas as tarefas de inicialização e está em um estado Ready do qual pode começar a aceitar nodes worker e executar tarefas enviadas ao Servidor de API. Agora você pode adicionar os workers a partir de sua máquina local.

      Passo 5 — Configurando os Nodes Worker

      A adição de workers ao cluster envolve a execução de um único comando em cada um. Este comando inclui as informações necessárias sobre o cluster, tais como o endereço IP e a porta do Servidor de API do master, e um token seguro. Somentes os nodes que passam no token seguro estarão aptos a ingressar no cluster.

      Navegue de volta para a sua área de trabalho e crie um playbook chamado workers.yml:

      • nano ~/kube-cluster/workers.yml

      Adicione o seguinte texto ao arquivo para adicionar os workers ao cluster:

      ~/kube-cluster/workers.yml

      
      - hosts: master
        become: yes
        gather_facts: false
        tasks:
          - name: get join command
            shell: kubeadm token create --print-join-command
            register: join_command_raw
      
          - name: set join command
            set_fact:
              join_command: "{{ join_command_raw.stdout_lines[0] }}"
      
      
      - hosts: workers
        become: yes
        tasks:
          - name: join cluster
            shell: "{{ hostvars['master'].join_command }} >> node_joined.txt"
            args:
              chdir: $HOME
              creates: node_joined.txt
      

      Aqui está o que o playbook faz:

      • O primeiro play obtém o comando de junção que precisa ser executado nos nodes workers. Este comando estará no seguinte formato: kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>. Assim que obtiver o comando real com os valores apropriados de token e hash, a tarefa define isso como um fact para que o próximo play possa acessar essa informação.

      • O segundo play tem uma única tarefa que executa o comando de junção em todos os nodes worker. Na conclusão desta tarefa, os dois nodes worker farão parte do cluster.

      Salve e feche o arquivo quando você tiver terminado.

      Rode o playbook localmente executando:

      • ansible-playbook -i hosts ~/kube-cluster/workers.yml

      Na conclusão, você verá uma saída semelhante à seguinte:

      Output

      PLAY [master] **** TASK [get join command] **** changed: [master] TASK [set join command] ***** ok: [master] PLAY [workers] ***** TASK [Gathering Facts] ***** ok: [worker1] ok: [worker2] TASK [join cluster] ***** changed: [worker1] changed: [worker2] PLAY RECAP ***** master : ok=2 changed=1 unreachable=0 failed=0 worker1 : ok=2 changed=1 unreachable=0 failed=0 worker2 : ok=2 changed=1 unreachable=0 failed=0

      Com a adição dos nodes worker, seu cluster está agora totalmente configurado e funcional, com os workers prontos para executar cargas de trabalho. Antes de fazer o scheduling de aplicações, vamos verificar se o cluster está funcionando conforme o esperado.

      Step 6 — Verificando o Cluster

      Às vezes, um cluster pode falhar durante a configuração porque um node está inativo ou a conectividade de rede entre o master e o worker não está funcionando corretamente. Vamos verificar o cluster e garantir que os nodes estejam operando corretamente.

      Você precisará verificar o estado atual do cluster a partir do node master para garantir que os nodes estejam prontos. Se você se desconectou do node master, pode voltar e fazer SSH com o seguinte comando:

      Em seguida, execute o seguinte comando para obter o status do cluster:

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

      Output

      NAME STATUS ROLES AGE VERSION master Ready master 1d v1.11.1 worker1 Ready <none> 1d v1.11.1 worker2 Ready <none> 1d v1.11.1

      Se todos os seus nodes têm o valor Ready para o STATUS, significa que eles são parte do cluster e estão prontos para executar cargas de trabalho.

      Se, contudo, alguns dos nodes têm NotReady como o STATUS, isso pode significar que os nodes worker ainda não concluíram sua configuração. Aguarde cerca de cinco a dez minutos antes de voltar a executar kubectl get nodes e fazer a inspeção da nova saída. Se alguns nodes ainda têm NotReady como status, talvez seja necessário verificar e executar novamente os comandos nas etapas anteriores.

      Agora que seu cluster foi verificado com sucesso, vamos fazer o scheduling de um exemplo de aplicativo Nginx no cluster.

      Step 7 — Executando Uma Aplicação no Cluster

      Você pode fazer o deploy de qualquer aplicação containerizada no seu cluster. Para manter as coisas familiares, vamos fazer o deploy do Nginx utilizando Deployments e Services para ver como pode ser feito o deploy dessa aplicação no cluster. Você também pode usar os comandos abaixo para outros aplicativos em container, desde que você altere o nome da imagem do Docker e quaisquer flags relevantes (tais como ports e volumes).

      Ainda no node master, execute o seguinte comando para criar um deployment chamado nginx:

      • kubectl run nginx --image=nginx --port 80

      Um deployment é um tipo de objeto do Kubernetes que garante que há sempre um número especificado de pods em execução com base em um modelo definido, mesmo se o pod falhar durante o tempo de vida do cluster. O deployment acima irá criar um pod com um container do registro do Docker Nginx Docker Image.

      A seguir, execute o seguinte comando para criar um serviço chamado nginx que irá expor o app publicamente. Ele fará isso por meio de um NodePort, um esquema que tornará o pod acessível através de uma porta arbitrária aberta em cada node do cluster:

      • kubectl expose deploy nginx --port 80 --target-port 80 --type NodePort

      Services são outro tipo de objeto do Kubernetes que expõe serviços do cluster para os clientes, tanto internos quanto externos. Eles também são capazes de fazer balanceamento de solicitações para vários pods e são um componente integral no Kubernetes, interagindo frequentemente com outros componentes.

      Execute o seguinte comando:

      Isso produzirá uma saída semelhante à seguinte:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d nginx NodePort 10.109.228.209 <none> 80:nginx_port/TCP 40m

      A partir da terceira linha da saída acima, você pode obter a porta em que o Nginx está sendo executado. O Kubernetes atribuirá uma porta aleatória maior que 30000 automaticamente, enquanto garante que a porta já não esteja vinculada a outro serviço.

      Para testar se tudo está funcionando, visite http://worker_1_ip:nginx_port ou http://worker_2_ip:nginx_port através de um navegador na sua máquina local. Você verá a familiar página de boas-vindas do Nginx.

      Se você quiser remover o aplicativo Nginx, primeiro exclua o serviço nginx do node master:

      • kubectl delete service nginx

      Execute o seguinte para garantir que o serviço tenha sido excluído:

      Você verá a seguinte saída:

      [secondary label Output]
      NAME         TYPE        CLUSTER-IP       EXTERNAL-IP           PORT(S)        AGE
      kubernetes   ClusterIP   10.96.0.1        <none>                443/TCP        1d
      

      Para excluir o deployment:

      • kubectl delete deployment nginx

      Execute o seguinte para confirmar que isso funcionou:

      Output

      No resources found.

      Conclusão

      Neste guia, você configurou com sucesso um cluster do Kubernetes no Ubuntu 18.04 usando Kubeadm e Ansible para automação.

      Se você está se perguntando o que fazer com o cluster, agora que ele está configurado, um bom próximo passo seria sentir-se confortável para implantar suas próprias aplicações e serviços no cluster. Aqui está uma lista de links com mais informações que podem orientá-lo no processo:

      • Dockerizing applications - lista exemplos que detalham como containerizar aplicações usando o Docker.

      • Pod Overview - descreve em detalhes como os Pods funcionam e seu relacionamento com outros objetos do Kubernetes. Os pods são onipresentes no Kubernetes, então compreendê-los facilitará seu trabalho.

      • Deployments Overview - fornece uma visão geral dos deployments. É útil entender como os controladores, como os deployments, funcionam, pois eles são usados com frequência em aplicações stateless para escalonamento e na recuperação automatizada de aplicações não íntegras.

      • Services Overview - cobre os serviços ou services, outro objeto frequentemente usado em clusters do Kubernetes. Entender os tipos de serviços e as opções que eles têm é essencial para executar aplicações stateless e stateful.

      Outros conceitos importantes que você pode analisar são Volumes, Ingresses e Secrets, os quais são úteis ao realizar o deploy de aplicações em produção.

      O Kubernetes tem muitas funcionalidades e recursos a oferecer. A Documentação Oficial do Kubernetes é o melhor lugar para aprender sobre conceitos, encontrar guias específicos de tarefas e procurar referências de API para vários objetos.

      Por bsder



      Source link