One place for hosting & domains

      Use journalctl to View Your System's Logs


      Updated by Linode

      Written by Linode


      Use promo code DOCS10 for $10 credit on a new account.

      What is journalctl?

      journalctl is a command for viewing logs collected by systemd. The systemd-journald service is responsible for systemd’s log collection, and it retrieves messages from the kernel, systemd services, and other sources.

      These logs are gathered in a central location, which makes them easy to review. The log records in the journal are structured and indexed, and as a result journalctl is able to present your log information in a variety of useful formats.

      Using journalctl for the First Time

      Run the journalctl command without any arguments to view all the logs in your journal:

      journalctl
      

      If you do not see output, try running it with sudo:

      sudo journalctl
      

      If your Linux user does not have sudo privileges, add your user to the sudo group.

      Default Log Format and Ordering

      journalctl will display your logs in a format similar to the traditional syslog format. Each line starts with the date (in the server’s local time), followed by the server’s hostname, the process name, and the message for the log.

        
      Aug 31 12:00:25 debian sshd[15844]: pam_unix(sshd:session): session opened for user example_user by (uid=0)
      
      

      Your logs will be displayed from oldest to newest. To reverse this order and display the newest messages at the top, use the -r flag:

      journalctl -r
      

      Paging through Your Logs

      journalctl pipes its output to the less command, which shows your logs one page at a time in your terminal. If a log line exceeds the horizontal width of your terminal window, you can use the left and right arrow keys to scroll horizontally and see the rest of the line:

      Furthermore, your logs can be navigated and searched by using all the same key commands available in less:

      Key command Action
      down arrow key, enter, e, or j Move down one line.
      up arrow key, y, or k Move up one line.
      space bar Move down one page.
      b Move up one page.
      right arrow key Scroll horizontally to the right.
      left arrow key Scroll horizontally to the left.
      g Go to the first line.
      G Go to the last line.
      10g Go to the 10th line. Enter a different number to go to other lines.
      50p or 50% Go to the line half-way through the output. Enter a different number to go to other percentage positions.
      /search term Search forward from the current position for the search term string.
      ?search term Search backward from the current position for the search term string.
      n When searching, go to the next occurrence.
      N When searching, go to the previous occurrence.
      m<c> Set a mark, which saves your current position. Enter a single character in place of <c> to label the mark with that character.
      '<c> Return to a mark, where <c> is the single character label for the mark. Note that ' is the single-quote.
      q Quit less

      View journalctl without Paging

      To send your logs to standard output and avoid paging them, use the --no-pager option:

      journalctl --no-pager
      

      It’s not recommended that you do this without first filtering down the number of logs shown.

      Monitor New Log Messages

      Run journalctl with the -f option to view a live log of new messages as they are collected:

      journalctl -f
      

      The key commands from less are not available while in this mode. Enter Control-C on your keyboard to return to your command prompt from this mode.

      Filter journalctl Output

      In addition to searching your logs with the less key commands, you can invoke journalctl with options that filter your log messages before they are displayed.

      These filters can be used with the normal paged display, and with the --no-pager and -f options. Filters of different types can also be combined together to further narrow the output.

      Show Logs within a Time Range

      Use the --since option to show logs after a specified date and time:

      journalctl --since "2018-08-30 14:10:10"
      

      Use the --until option to show logs up to a specified date and time:

      journalctl --until "2018-09-02 12:05:50"
      

      Combine these to show logs between the two times:

      journalctl --since "2018-08-30 14:10:10" --until "2018-09-02 12:05:50"
      

      Dates and times should be specified in the YYYY-MM-DD HH:MM:SS format. If the time is omitted (i.e. only the YYYY-MM-DD date is specified), then the time is assumed to be 00:00:00.

      journalctl can also accept some alternative terms when specifying dates:

      • The terms yesterday, today, and tomorrow are recognized. When using one of these terms, the time is assumed to be 00:00:00.

      • Terms like 1 day ago or 3 hours ago are recognized.

      • The - and + symbols can be used to specify relative dates. For example, -1h15min specifies 1 hour 15 minutes in the past, and +3h30min specifies 3 hours 30 minutes in the future.

      Show Logs for a Specific Boot

      Use the -b option to show logs for the last boot of your server:

      journalctl -b
      

      Specify an integer offset for the -b option to refer to a previous boot. For example, journalctl -b -1 show logs from the previous boot, journalctl -b -2 shows logs from the boot before the previous boot, and so on.

      List the available boots:

      journalctl --list-boots
      

      Each boot listed in the output from journalctl --list-boots command includes a 32-bit boot ID. You can supply a boot ID with the -b option; for example:

      journalctl -b a09dce7b2c1c458d861d7d0f0a7c8c65
      

      If no previous boots are listed, your journald configuration may not be set up to persist log storage. Review the Persist Your Logs section for instructions on how to change this configuration.

      Show Logs for a systemd Service

      Pass the name of a systemd unit with the -u option to show logs for that service:

      journalctl -u ssh
      

      View Kernel Messages

      Supply the -k option to show only kernel messages:

      journalctl -k
      

      Change the Log Output Format

      Because the log records for systemd’s journals are structured, journalctl can show your logs in different formats. Here are a few of the formats available:

      Format Name Description
      short The default option, displays logs in the traditional syslog format.
      verbose Displays all information in the log record structure.
      json Displays logs in JSON format, with one log per line.
      json-pretty Displays logs in JSON format across multiple lines for better readability.
      cat Displays only the message from each log without any other metadata.

      Pass the format name with the -o option to display your logs in that format. For example:

      journalctl -o json-pretty
      

      Anatomy of a Log Record

      The following is an example of the structured data of a log record, as displayed by journalctl -o verbose. For more information on this data structure, review the man page for journalctl:

        
      Fri 2018-08-31 12:00:25.543177 EDT [s=0b341b44cf194c9ca45c99101497befa;i=70d5;b=a09dce7b2c1c458d861d7d0f0a7c8c65;m=9fb524664c4;t=57517dfc5f57d;x=97097ca5ede0dfd6]
          _BOOT_ID=a09dce7b2c1c458d861d7d0f0a7c8c65
          _MACHINE_ID=1009f49fff8fe746a5111e1a062f4848
          _HOSTNAME=debian
          _TRANSPORT=syslog
          PRIORITY=6
          SYSLOG_IDENTIFIER=sshd
          _UID=0
          _GID=0
          _COMM=sshd
          _EXE=/usr/sbin/sshd
          _CAP_EFFECTIVE=3fffffffff
          _SYSTEMD_CGROUP=/system.slice/ssh.service
          _SYSTEMD_UNIT=ssh.service
          _SYSTEMD_SLICE=system.slice
          SYSLOG_FACILITY=10
          SYSLOG_PID=15844
          _PID=15844
          _CMDLINE=sshd: example_user [priv
          MESSAGE=pam_unix(sshd:session): session opened for user example_user by (uid=0)
          _AUDIT_SESSION=30791
          _AUDIT_LOGINUID=1000
          _SOURCE_REALTIME_TIMESTAMP=1536120282543177
      
      

      Note

      In addition to the types of filters listed in the previous section, you can also filter logs by specifying values for the variables in the log record structure. For example, journalctl _UID=0 will show logs for user ID 0 (i.e. the root user).

      Persist Your Logs

      systemd-journald can be configured to persist your systemd logs on disk, and it also provides controls to manage the total size of your archived logs. These settings are defined in /etc/systemd/journald.conf.

      To start persisting your logs, uncomment the Storage line in /etc/systemd/journald.conf and set its value to persistent. Your archived logs will be held in /var/log/journal. If this directory does not already exist in your file system, systemd-journald will create it.

      After updating your journald.conf, load the change:

      sudo systemctl restart systemd-journald
      

      Control the Size of Your Logs’ Disk Usage

      The following settings in journald.conf control how large your logs’ size can grow to when persisted on disk:

      Setting Description
      SystemMaxUse The total maximum disk space that can be used for your logs.
      SystemKeepFree The minimum amount of disk space that should be kept free for uses outside of systemd-journald’s logging functions.
      SystemMaxFileSize The maximum size of an individual journal file.
      SystemMaxFiles The maximum number of journal files that can be kept on disk.

      systemd-journald will respect both SystemMaxUse and SystemKeepFree, and it will set your journals’ disk usage to meet whichever setting results in a smaller size.

      To view your default limits, run:

      sudo journalctl -u systemd-journald
      

      You should see a line similar to the following which describes the current limits in place:

        
      Permanent journal is using 32.0M (max allowed 2.3G, trying to leave 3.5G free of 21.2G available → current limit 2.3G).
      
      

      Note

      A parallel group of settings is used when journald.conf is set to only persist the journals in memory (instead of on disk): RuntimeMaxUse, RuntimeKeepFree, RuntimeMaxFileSize, and RuntimeMaxFiles.

      Manually Clean Up Archived Logs

      journalctl offers functions for immediately removing archived journals on disk. Run journalctl with the --vacuum-size option to remove archived journal files until the total size of your journals is less than the specified amount. For example, the following command will reduce the size of your journals to 2GiB:

      journalctl --vacuum-size=2G
      

      Run journalctl with the --vacuum-time option to remove archived journal files with dates older than the specified relative time. For example, the following command will remove journals older than one year:

      journalctl --vacuum-time=1years
      

      Run journalctl with the --vacuum-files option to remove archived journal files until the specified number of files remains. For example, the following command removes all but the 10 most recent journal files:

      journalctl --vacuum-files=10
      

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      Join our Community

      Find answers, ask questions, and help others.

      This guide is published under a CC BY-ND 4.0 license.



      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

      WordPress security beyond updates


      One of the reasons for the tremendous popularity of WordPress is that it is open source. As open source software, the bare bones of WordPress are free, and the huge ecosystem of themes, plugins, and other extensions that developers are able to create can be combined in countless different ways to build practically any kind of unique, high-quality website. While this ecosystem is what gives WordPress its flexibility and range of capabilities, it is also the chief source of security concerns for websites using the leading content management platform.

      Of just under 4,000 known WordPress vulnerabilities, plugins make up more than half, according to a recent report by wpscan.org. More than a third are found in the WordPress core, and 11 percent are from Themes. Many of these vulnerabilities can be mitigated simply by applying the next update to your WordPress core and each of your plugins, as developers are alerted of vulnerabilities and make changes to eliminate them.

      Keeping everything up to date and using a complex password are the low-hanging fruit of website security. You can set WordPress to automatically apply core updates, and you can also install a plugin to automatically update your other plugins. There are also security-specific plugins to provide functions like malware scanning and a firewall.

      Beyond these basics, there are a few other simple things that WordPress website operators can do to improve the security of their sites.

      Unreliable or untrustworthy sources

      Plugins from even the most professional and responsible developers have vulnerabilities – it is inevitable that hackers will find new ways to compromise previously secure programs and systems, forcing the developer to react with an update. Most attacks are not new, however, but are directed at vulnerabilities that should have already been dealt with.

      A developer that is slow to close vulnerabilities with updates, or that does so improperly, may leave sites exposed even if everything is up to date. Even worse, a few free or cheap alternatives to popular plugins contain malware or built in-vulnerabilities for the specific purpose of attacking every site they are used in.

      File and folder permissions

      It is generally not necessary or advised for WordPress users to modify permissions for who can read, write, and execute (or run) files and folders. It is important that permissions are set properly, however, and if they have been set too broadly, a malicious actor could potentially take complete control over your site. If you discover a permission has been set to 777, it means that owners, privileged users, and the general public all have permission to modify your site in any way, should they gain access to it.

      To change permissions, you need to use an FTP client. Once you have connected to your site, you can right click on root directories and then edit permissions by clicking on “File permissions” in the menu. Enter the recommended setting in the “Numeric field,” which for most users is 755 for all folder and sub-folders, and make sure that “Recurse into subdirectories” is checked, and click “Apply to directories only.” After you click “OK,” it will take a few seconds to make the changes, after which you can move onto files, by highlighting everything in the sites root folder and following the same procedure to bring up the “File permissions” dialogue box. For most users the permission is set at 644, and “Recurse into subdirectories” and “Apply to files only” are checked.

      Two-factor authentication

      Two-factor authentication, or 2FA, adds an extra layer of security to your WordPress sign-in process. You can apply it with any one of several popular plugins, some of which use the Google Authenticator app to provide the second factor (in the form of a token), often by sending you a one-time password (OTP) to enter along with your usual credentials.

      The plugin may provide options to send the OTP to your email account or mobile device, so that an attacker can only gain access to your site by both knowing your password and stealing your device or hacking your email account. It may also use another factor, such as a QR code that you scan. Some plugins provide an option to use a token along with either a username and password, or just a username. Whichever you choose, select a plugin that has been tested with the current version of WordPress.

      Tools and resources

      There are a number of useful tools and resources that have been created specifically for improving WordPress security, due to the platform’s enormous popularity.

      WPScan.org offers a free tool for scanning WordPress sites for vulnerabilities, allowing you to address them before they are exploited. Companies in the WordPress ecosystem provide useful resources, like the “Learning Center” provided by security plugin developer Wordfence, which includes a nine-part series for dealing with malware. WordPress.org also offers quality documentation and forums, like any major software provider, which contain a lot of answers to security-related questions.

      A quality managed service provider like TMD can also help WordPress users harden their perimeter and protect their websites. Just by taking a step beyond updates, any kind of business can have a secure, cost-effective, beautiful website.



      Source link