Como Fazer o Benchmark de um Servidor Redis no Ubuntu 18.04

Introdução

O Benchmarking é uma prática importante quando se trata de analisar o desempenho geral dos servidores de banco de dados. É útil para identificar gargalos e oportunidades de melhoria nesses sistemas.

O Redis é um armazenamento de estrutura dados em memória que pode ser usado como banco de dados, cache e intermediador de mensagens ou message broker. Ele suporta desde estruturas de dados simples a complexas, incluindo hashes, strings, conjuntos classificados, bitmaps, dados geoespaciais, entre outros tipos. Neste guia, demonstraremos como fazer o benchmark de um servidor Redis em execução no Ubuntu 18.04, usando algumas ferramentas e métodos distintos.

Pré-requisitos

Para seguir este guia, você precisará de:

Nota: Os comandos demonstrados neste tutorial foram executados em um servidor Redis dedicado rodando em um Droplet da DigitalOcean de 4 GB.

Usando a ferramenta incluída redis-benchmark

O Redis vem com uma ferramenta de benchmark chamada redis-benchmark. Este programa pode ser usado para simular um número arbitrário de clientes se conectando ao mesmo tempo e executando ações no servidor, medindo quanto tempo leva para que as solicitações sejam concluídas. Os dados resultantes vão lhe fornecer uma ideia do número médio de solicitações que o seu servidor Redis é capaz de processar por segundo.

A lista a seguir detalha algumas das opções de comando comuns usadas com o redis-benchmark:

  • -h: Host do Redis. O padrão é 127.0.0.1.
  • -p: Porta do Redis. O padrão é 6379.
  • -a: Se o seu servidor exigir autenticação, você poderá usar esta opção para fornecer a senha.
  • -c: Número de clientes (conexões paralelas) a serem simulados. O valor padrão é 50.
  • -n: Quantas requisições a fazer. O padrão é 100000.
  • -d: Tamanho dos dados para os valores de SET e GET, medidos em bytes. O padrão é 3.
  • -t: Execute apenas um subconjunto de testes. Por exemplo, você pode usar -t get,set para fazer o benchmark dos comandos GET e SET.
  • -q: Modo silencioso, mostra apenas a informação sobre média de requisições por segundo.

Por exemplo, se você deseja verificar o número médio de solicitações por segundo que o seu servidor Redis local pode suportar, você pode usar:

  • redis-benchmark -q

Você obterá resultados semelhantes a este, mas com números diferentes:

Output
PING_INLINE: 85178.88 requests per second PING_BULK: 83056.48 requests per second SET: 72202.16 requests per second GET: 94607.38 requests per second INCR: 84961.77 requests per second LPUSH: 78988.94 requests per second RPUSH: 88652.48 requests per second LPOP: 87950.75 requests per second RPOP: 80971.66 requests per second SADD: 80192.46 requests per second HSET: 84317.03 requests per second SPOP: 78125.00 requests per second LPUSH (needed to benchmark LRANGE): 84175.09 requests per second LRANGE_100 (first 100 elements): 52383.45 requests per second LRANGE_300 (first 300 elements): 21547.08 requests per second LRANGE_500 (first 450 elements): 14471.78 requests per second LRANGE_600 (first 600 elements): 9383.50 requests per second MSET (10 keys): 71225.07 requests per second

Você também pode limitar os testes a um subconjunto de comandos de sua escolha usando o parâmetro -t. O comando a seguir mostra as médias apenas dos comandos GET eSET:

  • redis-benchmark -t set,get -q
Output
SET: 76687.12 requests per second GET: 82576.38 requests per second

As opções padrão usarão 50 conexões paralelas para criar 100000 requisições ao servidor Redis. Se você deseja aumentar o número de conexões paralelas para simular um pico de uso, pode usar a opção -c para isso:

  • redis-benchmark -t set,get -q -c 1000

Como isso usará 1000 conexões simultâneas em vez das 50 padrão, você deve esperar uma diminuição no desempenho:

Output
SET: 69444.45 requests per second GET: 70821.53 requests per second

Se você quiser informações detalhadas na saída, poderá remover a opção -q. O comando a seguir usará 100 conexões paralelas para executar 1000000 requisições SET no servidor:

  • redis-benchmark -t set -c 100 -n 1000000

Você obterá uma saída semelhante a esta:

Output
====== SET ====== 1000000 requests completed in 11.29 seconds 100 parallel clients 3 bytes payload keep alive: 1 95.22% <= 1 milliseconds 98.97% <= 2 milliseconds 99.86% <= 3 milliseconds 99.95% <= 4 milliseconds 99.99% <= 5 milliseconds 99.99% <= 6 milliseconds 100.00% <= 7 milliseconds 100.00% <= 8 milliseconds 100.00% <= 8 milliseconds 88605.35 requests per second

As configurações padrão usam 3 bytes para valores de chave. Você pode mudar isso com a opção -d. O comando a seguir fará o benchmark dos comandos GET e SET usando valores de chave de 1 MB:

  • redis-benchmark -t set,get -d 1000000 -n 1000 -q

Como o servidor está trabalhando com um payload muito maior dessa vez, espera-se uma diminuição significativa do desempenho:

Output
SET: 1642.04 requests per second GET: 822.37 requests per second

É importante perceber que, embora esses números sejam úteis como uma maneira rápida de avaliar o desempenho de uma instância Redis, eles não representam a taxa de transferência máxima que uma instância Redis pode suportar. Usando pipelining, as aplicações podem enviar vários comandos ao mesmo tempo para melhorar o número de requisições por segundo que o servidor pode manipular. Com o redis-benchmark, você pode usar a opção -P para simular aplicações do mundo real que fazem uso desse recurso do Redis.

Para comparar a diferença, primeiro execute o comando redis-benchmark com valores padrão e sem pipelining, para os testes GET e SET:

  • redis-benchmark -t get,set -q
Output
SET: 86281.27 requests per second GET: 89847.26 requests per second

O próximo comando executará os mesmos testes, mas fará o pipeline de 8 comandos juntos:

  • redis-benchmark -t get,set -q -P 8
Output
SET: 653594.81 requests per second GET: 793650.75 requests per second

Como você pode ver na saída, há uma melhoria substancial no desempenho com o uso de pipelining.

Checando a Latência com redis-cli

Se você deseja uma medição simples do tempo médio que uma requisição leva para receber uma resposta, você pode usar o cliente Redis para verificar a latência média do servidor. No contexto do Redis, latência é uma medida de quanto tempo um comando ping leva para receber uma resposta do servidor.

O comando a seguir mostrará estatísticas de latência em tempo real para seu servidor Redis:

  • redis-cli --latency

Você obterá uma saída semelhante a esta, mostrando um número crescente de amostras e uma latência média variável:

Output
min: 0, max: 1, avg: 0.18 (970 samples)

Este comando continuará sendo executado indefinidamente. Você pode pará-lo com um CTRL+C.

Para monitorar a latência por um determinado período, você pode usar:

  • redis-cli --latency-history

Isso irá acompanhar as médias de latência ao longo do tempo, com um intervalo configurável definido como 15 segundos por padrão. Você obterá uma saída semelhante a esta:

Output
min: 0, max: 1, avg: 0.18 (1449 samples) -- 15.01 seconds range min: 0, max: 1, avg: 0.16 (1449 samples) -- 15.00 seconds range min: 0, max: 1, avg: 0.17 (1449 samples) -- 15.00 seconds range min: 0, max: 1, avg: 0.17 (1444 samples) -- 15.01 seconds range min: 0, max: 1, avg: 0.17 (1446 samples) -- 15.01 seconds range min: 0, max: 1, avg: 0.17 (1449 samples) -- 15.00 seconds range min: 0, max: 1, avg: 0.16 (1444 samples) -- 15.00 seconds range min: 0, max: 1, avg: 0.17 (1445 samples) -- 15.01 seconds range min: 0, max: 1, avg: 0.16 (1445 samples) -- 15.01 seconds range …

Como o servidor Redis em nosso exemplo está ocioso, não há muita variação entre as amostras de latência. Se você tem um pico de uso, no entanto, isso deve ser refletido como um aumento na latência dentro dos resultados.

Se você deseja medir apenas a latência do sistema, pode usar --intrinsic-latency para isso. A latência intrínseca é inerente ao ambiente, dependendo de fatores como hardware, kernel, vizinhança do servidor e outros fatores que não são controlados pelo Redis.

Você pode ver a latência intrínseca como uma linha de base para o desempenho geral do Redis. O comando a seguir verificará a latência intrínseca do sistema, executando um teste por 30 segundos:

  • redis-cli --intrinsic-latency 30

Você deve obter uma saída semelhante a esta:

Output
… 498723744 total runs (avg latency: 0.0602 microseconds / 60.15 nanoseconds per run). Worst run took 22975x longer than the average latency.

Comparar os dois testes de latência pode ser útil para identificar gargalos de hardware ou sistema que podem afetar o desempenho do seu servidor Redis. Considerando que a latência total de uma requisição para o nosso servidor de exemplo tem uma média de 0,18 microssegundos para concluir, uma latência intrínseca de 0,06 microssegundos significa que um terço do tempo total da requisição é gasto pelo sistema em processos que não são controlados pelo Redis.

Usando a Ferramenta Memtier Benchmark

O Memtier é uma ferramenta de benchmark de alto rendimento para Redis e Memcached criada pelo Redis Labs. Embora muito parecido com o redis-benchmark em vários aspectos, o Memtier possui várias opções de configuração que podem ser ajustadas para emular melhor o tipo de carga que você pode esperar no seu servidor Redis, além de oferecer suporte a cluster.

Para instalar o Memtier em seu servidor, você precisará compilar o software a partir do código-fonte. Primeiro, instale as dependências necessárias para compilar o código:

  • sudo apt-get install build-essential autoconf automake libpcre3-dev libevent-dev pkg-config zlib1g-dev

Em seguida, vá para o seu diretório home e clone o projeto memtier_benchmark do repositório Github:

  • cd
  • git clone https://github.com/RedisLabs/memtier_benchmark.git

Navegue para o diretório do projeto e execute o comando autoreconf para gerar os scripts de configuração do aplicativo:

  • cd memtier_benchmark
  • autoreconf -ivf

Execute o script configure para gerar os artefatos do aplicativo necessários para a compilação:

  • ./configure

Agora execute make para compilar o aplicativo:

  • make

Após a conclusão da compilação, você pode testar o executável com:

  • ./memtier_benchmark --version

Isso lhe fornecerá a seguinte saída:

Output
memtier_benchmark 1.2.17 Copyright (C) 2011-2017 Redis Labs Ltd. This is free software. You may redistribute copies of it under the terms of the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. There is NO WARRANTY, to the extent permitted by law.

A lista a seguir contém algumas das opções mais comuns usadas com o comando memtier_benchmark:

  • -s: Host do Servidor. O padrão é localhost.
  • -p: Porta do Servidor. O padrão é 6379.
  • -a: Autentica requisições usando a senha fornecida.
  • -n: Número de requisições por cliente (o padrão é 10000).
  • -c: Número de clientes (o padrão é 50).
  • -t: Número de threads (o padrão é 4).
  • --pipeline: Ativar pipelining.
  • --ratio: Relação entre os comandos SET e GET, o padrão é 1:10.
  • --hide-histogram: Oculta informações detalhadas de saída.

A maioria dessas opções é muito semelhante às opções presentes no redis-benchmark, mas o Memtier testa o desempenho de uma maneira diferente. Para simular melhor os ambientes comuns do mundo real, o benchmark padrão realizado pelo memtier_benchmark testará apenas as solicitações GET e SET, na proporção de 1 a 10. Com 10 operações GET para cada operação SET no teste, esse arranjo é mais representativo de uma aplicação web comum usando o Redis como banco de dados ou cache. Você pode ajustar o valor da taxa com a opção --ratio.

O comando a seguir executa o memtier_benchmark com as configurações padrão, fornecendo apenas informações de saída de alto nível:

  • ./memtier_benchmark --hide-histogram

Nota: se você configurou seu servidor Redis para exigir autenticação, você deve fornecer a opção -a junto com sua senha Redis ao comando memtier_benchmark:

  • ./memtier_benchmark --hide-histogram -a sua_senha_redis

Você verá resultados semelhantes a este:

Output
… 4 Threads 50 Connections per thread 10000 Requests per client ALL STATS ========================================================================= Type Ops/sec Hits/sec Misses/sec Latency KB/sec ------------------------------------------------------------------------- Sets 8258.50 --- --- 2.19800 636.05 Gets 82494.28 41483.10 41011.18 2.19800 4590.88 Waits 0.00 --- --- 0.00000 --- Totals 90752.78 41483.10 41011.18 2.19800 5226.93

De acordo com esta execução do memtier_benchmark, nosso servidor Redis pode executar cerca de 90 mil operações por segundo na proporção 1:10 SET/GET.

É importante observar que cada ferramenta de benchmark possui seu próprio algoritmo para teste de desempenho e apresentação de dados. Por esse motivo, é normal ter resultados ligeiramente diferentes no mesmo servidor, mesmo utilizando configurações semelhantes.

Conclusão

Neste guia, demonstramos como executar testes de benchmark em um servidor Redis usando duas ferramentas distintas: o redis-benchmark incluído e a ferramenta memtier_benchmark desenvolvida pelo Redis Labs. Também vimos como verificar a latência do servidor usando redis-cli. Com base nos dados obtidos com esses testes, você entenderá melhor o que esperar do servidor Redis em termos de desempenho e quais são os gargalos da sua configuração atual.

DigitalOcean Community Tutorials

Como Configurar um Banco de Dados Remoto para Otimizar o Desempenho do Site com o MySQL no Ubuntu 18.04

Introdução

À medida que sua aplicação ou site cresce, pode chegar um momento em que você superou a configuração atual do seu servidor. Se você estiver hospedando o seu servidor web e o back-end do banco de dados na mesma máquina, pode ser uma boa ideia separar essas duas funções para que cada uma possa operar em seu próprio hardware e compartilhar a carga de responder às solicitações dos visitantes.

Neste guia, veremos como configurar um servidor de banco de dados MySQL remoto ao qual sua aplicação web pode se conectar. Usaremos o WordPress como exemplo para ter algo para trabalhar, mas a técnica é amplamente aplicável a qualquer aplicação suportada pelo MySQL.

Pré-requisitos

Antes de iniciar este tutorial, você precisará de:

  • Dois servidores Ubuntu 18.04. Cada um deles deve ter um usuário não-root com privilégios sudo e um firewall UFW habilitado, conforme descrito em nosso tutorial de Configuração Inicial de servidor com Ubuntu 18.04. Um desses servidores hospedará seu back-end MySQL e, ao longo deste guia, o chamaremos de servidor de banco de dados. O outro se conectará ao seu servidor de banco de dados remotamente e atuará como seu servidor web; da mesma forma, iremos nos referir a ele como servidor web ao longo deste guia.
  • Nginx e PHP instalado em seu servidor web. Nosso tutorial How To Install Linux, Nginx, MySQL, PHP (LEMP stack) in Ubuntu 18.04 o guiará no processo, mas observe que você deve pular o Passo 2 deste tutorial, que se concentra na instalação do MySQL, pois você instalará o MySQL no seu servidor de banco de dados.
  • MySQL instalado em seu servidor de banco de dados. Siga o tutorial Como Instalar o MySQL no Ubuntu 18.04 para configurar isso.
  • Opcionalmente (mas altamente recomendado), certificados TLS/SSL da Let’s Encrypt instalados em seu servidor web. Você precisará comprar um nome de domínio e ter registros DNS configurados para seu servidor, mas os certificados em si são gratuitos. Nosso guia Como Proteger o Nginx com o Let’s Encrypt no Ubuntu 18.04 lhe mostrará como obter esses certificados.

Passo 1 — Configurando o MySQL para Escutar Conexões Remotas

Ter os dados armazenados em um servidor separado é uma boa maneira de expandir elegantemente após atingir o limite máximo de desempenho de uma configuração de uma única máquina. Ela também fornece a estrutura básica necessária para balancear a carga e expandir sua infraestrutura ainda mais posteriormente. Após instalar o MySQL, seguindo o tutorial de pré-requisitos, você precisará alterar alguns valores de configuração para permitir conexões a partir de outros computadores.

A maioria das mudanças na configuração do servidor MySQL pode ser feita no arquivo mysqld.cnf, que é armazenado no diretório /etc/mysql/mysql.conf.d/ por padrão. Abra este arquivo em seu servidor de banco de dados com privilégios de root em seu editor preferido. Aqui, iremos usar o nano:

  • sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Este arquivo é dividido em seções indicadas por labels entre colchetes ([ e ]). Encontre a seção com o label mysqld:

/etc/mysql/mysql.conf.d/mysqld.cnf
. . . [mysqld] . . . 

Nesta seção, procure um parâmetro chamado bind-address. Isso informa ao software do banco de dados em qual endereço de rede escutar as conexões.

Por padrão, isso está definido como 127.0.0.1, significando que o MySQL está configurado para escutar apenas conexões locais. Você precisa alterar isso para fazer referência a um endereço IP externo onde seu servidor pode ser acessado.

Se os dois servidores estiverem em um datacenter com recursos de rede privada, use o IP da rede privada do seu servidor de banco de dados. Caso contrário, você pode usar seu endereço IP público:

/etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld] . . . bind-address = ip_do_servidor_de_banco_de_dados 

Como você se conectará ao seu banco de dados pela Internet, é recomendável que você exija conexões criptografadas para manter seus dados seguros. Se você não criptografar sua conexão MySQL, qualquer pessoa na rede poderá fazer sniff por informações confidenciais entre seus servidores web e de banco de dados. Para criptografar conexões MySQL, adicione a seguinte linha após a linha bind-address que você acabou de atualizar:

/etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld] . . . require_secure_transport = on . . . 

Salve e feche o arquivo quando terminar. Se você estiver usando nano, faça isso pressionando CTRL+X, Y e, em seguida, ENTER.

Para que as conexões SSL funcionem, você precisará criar algumas chaves e certificados. O MySQL vem com um comando que os configura automaticamente. Execute o seguinte comando, que cria os arquivos necessários. Ele também os torna legíveis pelo servidor MySQL, especificando o UID do usuário mysql:

  • sudo mysql_ssl_rsa_setup --uid=mysql

Para forçar o MySQL a atualizar sua configuração e ler as novas informações de SSL, reinicie o banco de dados:

  • sudo systemctl restart mysql

Para confirmar que o servidor agora está escutando na interface externa, execute o seguinte comando netstat:

  • sudo netstat -plunt | grep mysqld
Output
tcp 0 0 ip_do_servidor_de_banco_de_dados:3306 0.0.0.0:* LISTEN 27328/mysqld

O netstat imprime estatísticas sobre o sistema de rede do seu servidor. Esta saída nos mostra que um processo chamado mysqld está anexado ao ip_do_servidor_de_banco_de_dados na porta 3306, a porta padrão do MySQL, confirmando que o servidor está escutando na interface apropriada.

Em seguida, abra essa porta no firewall para permitir o tráfego através dela:

  • sudo ufw allow mysql

Essas são todas as alterações de configuração que você precisa fazer no MySQL. A seguir, veremos como configurar um banco de dados e alguns perfis de usuário, um dos quais você usará para acessar o servidor remotamente.

Passo 2 — Configurando um Banco de Dados para o WordPress e Credenciais Remotas

Embora o próprio MySQL agora esteja escutando em um endereço IP externo, atualmente não há usuários ou bancos de dados habilitados para controle remoto configurados. Vamos criar um banco de dados para o WordPress e um par de usuários que possam acessá-lo.

Comece conectando-se ao MySQL como o usuário root do MySQL:

  • sudo mysql

Nota: Se você tiver a autenticação por senha ativada, conforme descrito no Passo 3 do pré-requisito do tutorial do MySQL, você precisará usar o seguinte comando para acessar o shell do MySQL:

  • mysql -u root -p

Depois de executar este comando, você será solicitado a fornecer sua senha de root do MySQL e, após inseri-la, receberá um novo prompt mysql>.

No prompt do MySQL, crie um banco de dados que o WordPress usará. Pode ser útil atribuir a esse banco de dados um nome reconhecível para que você possa identificá-lo facilmente mais tarde. Aqui, vamos chamá-lo de wordpress:

  • CREATE DATABASE wordpress;

Agora que você criou seu banco de dados, você precisará criar um par de usuários. Criaremos um usuário somente local e um usuário remoto vinculado ao endereço IP do servidor web.

Primeiro, crie seu usuário local, wpuser, e faça com que esta conta corresponda apenas às tentativas de conexão local usando localhost na declaração:

  • CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'senha';

Em seguida, conceda a esta conta acesso total ao banco de dados wordpress:

  • GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';

Agora, esse usuário pode executar qualquer operação no banco de dados do WordPress, mas essa conta não pode ser usada remotamente, pois corresponde apenas às conexões da máquina local. Com isso em mente, crie uma conta complementar que corresponda às conexões exclusivamente do seu servidor web. Para isso, você precisará do endereço IP do seu servidor web.

Observe que você deve usar um endereço IP que utilize a mesma rede que você configurou no seu arquivo mysqld.cnf. Isso significa que, se você especificou um IP de rede privada no arquivo mysqld.cnf, precisará incluir o IP privado do seu servidor web nos dois comandos a seguir. Se você configurou o MySQL para usar a internet pública, você deve fazer isso corresponder ao endereço IP público do servidor web.

  • CREATE USER 'remotewpuser'@'ip_do_servidor_web' IDENTIFIED BY 'senha';

Depois de criar sua conta remota, conceda a ela os mesmos privilégios que o usuário local:

  • GRANT ALL PRIVILEGES ON wordpress.* TO 'remotewpuser'@'ip_do_servidor_web';

Por fim, atualize os privilégios para que o MySQL saiba começar a usá-los:

  • FLUSH PRIVILEGES;

Então saia do prompt do MySQL digitando:

  • exit

Agora que você configurou um novo banco de dados e um usuário habilitado remotamente, você pode testar se consegue se conectar ao banco de dados a partir do seu servidor web.

Passo 3 — Testando Conexões Remotas e Locais

Antes de continuar, é melhor verificar se você pode se conectar ao seu banco de dados tanto a partir da máquina local — seu servidor de banco de dados — quanto pelo seu servidor web.

Primeiro, teste a conexão local a partir do seu servidor de banco de dados tentando fazer login com sua nova conta:

  • mysql -u wpuser -p

Quando solicitado, digite a senha que você configurou para esta conta.

Se você receber um prompt do MySQL, então a conexão local foi bem-sucedida. Você pode sair novamente digitando:

  • exit

Em seguida, faça login no seu servidor web para testar as conexões remotas:

  • ssh sammy@ip_do_servidor_web

Você precisará instalar algumas ferramentas de cliente para MySQL em seu servidor web para acessar o banco de dados remoto. Primeiro, atualize o cache de pacotes local se você não tiver feito isso recentemente:

  • sudo apt update

Em seguida, instale os utilitários de cliente do MySQL:

  • sudo apt install mysql-client

Depois disso, conecte-se ao seu servidor de banco de dados usando a seguinte sintaxe:

  • mysql -u remotewpuser -h ip_do_servidor_de_banco_de_dados -p

Novamente, você deve certificar-se que está usando o endereço IP correto para o servidor de banco de dados. Se você configurou o MySQL para escutar na rede privada, digite o IP da rede privada do seu banco de dados. Caso contrário, digite o endereço IP público do seu servidor de banco de dados.

Você será solicitado a inserir a senha da sua conta remotewpuser. Depois de inseri-la, e se tudo estiver funcionando conforme o esperado, você verá o prompt do MySQL. Verifique se a conexão está usando SSL com o seguinte comando:

  • status

Se a conexão realmente estiver usando SSL, a linha SSL: indicará isso, como mostrado aqui:

Output
-------------- mysql Ver 14.14 Distrib 5.7.18, for Linux (x86_64) using EditLine wrapper Connection id: 52 Current database: Current user: remotewpuser@203.0.113.111 SSL: Cipher in use is DHE-RSA-AES256-SHA Current pager: stdout Using outfile: '' Using delimiter: ; Server version: 5.7.18-0ubuntu0.16.04.1 (Ubuntu) Protocol version: 10 Connection: 203.0.113.111 via TCP/IP Server characterset: latin1 Db characterset: latin1 Client characterset: utf8 Conn. characterset: utf8 TCP port: 3306 Uptime: 3 hours 43 min 40 sec Threads: 1 Questions: 1858 Slow queries: 0 Opens: 276 Flush tables: 1 Open tables: 184 Queries per second avg: 0.138 --------------

Depois de verificar que você pode se conectar remotamente, vá em frente e saia do prompt:

  • exit

Com isso, você verificou o acesso local e o acesso a partir do servidor web, mas não verificou se outras conexões serão recusadas. Para uma verificação adicional, tente fazer o mesmo em um terceiro servidor para o qual você não configurou uma conta de usuário específica para garantir que esse outro servidor não tenha o acesso concedido.

Observe que antes de executar o seguinte comando para tentar a conexão, talvez seja necessário instalar os utilitários de cliente do MySQL, como você fez acima:

  • mysql -u wordpressuser -h ip_do_servidor_de_banco_de_dados -p

Isso não deve ser concluído com êxito e deve gerar um erro semelhante a este:

Output
ERROR 1130 (HY000): Host '203.0.113.12' is not allowed to connect to this MySQL server

Isso é esperado, já que você não criou um usuário do MySQL que tem permissão para se conectar a partir deste servidor, e também é desejado, uma vez que você quer ter certeza de que seu servidor de banco de dados negará o acesso de usuários não autorizados ao seu servidor do MySQL.

Após testar com êxito sua conexão remota, você pode instalar o WordPress em seu servidor web.

Passo 4 — Instalando o WordPress

Para demonstrar os recursos do seu novo servidor MySQL com capacidade remota, passaremos pelo processo de instalação e configuração do WordPress — o popular sistema de gerenciamento de conteúdo — em seu servidor web. Isso exigirá que você baixe e extraia o software, configure suas informações de conexão e então execute a instalação baseada em web do WordPress.

No seu servidor web, faça o download da versão mais recente do WordPress para o seu diretório home:

  • cd ~
  • curl -O https://wordpress.org/latest.tar.gz

Extraia os arquivos, que criarão um diretório chamado wordpress no seu diretório home:

  • tar xzvf latest.tar.gz

O WordPress inclui um arquivo de configuração de exemplo que usaremos como ponto de partida. Faça uma cópia deste arquivo, removendo -sample do nome do arquivo para que ele seja carregado pelo WordPress:

  • cp ~/wordpress/wp-config-sample.php ~/wordpress/wp-config.php

Quando você abre o arquivo, sua primeira abordagem será ajustar algumas chaves secretas para fornecer mais segurança à sua instalação. O WordPress fornece um gerador seguro para esses valores, para que você não precise criar bons valores por conta própria. Eles são usados apenas internamente, portanto, não prejudicará a usabilidade ter valores complexos e seguros aqui.

Para obter valores seguros do gerador de chave secreta do WordPress, digite:

  • curl -s https://api.wordpress.org/secret-key/1.1/salt/

Isso imprimirá algumas chaves na sua saída. Você as adicionará momentaneamente ao seu arquivo wp-config.php:

Atenção! É importante que você solicite seus próprios valores únicos sempre. Não copie os valores mostrados aqui!

Output
define('AUTH_KEY', 'L4|2Yh(giOtMLHg3#] DO NOT COPY THESE VALUES %G00o|te^5YG@)'); define('SECURE_AUTH_KEY', 'DCs-k+MwB90/-E(=!/ DO NOT COPY THESE VALUES +WBzDq:7U[#Wn9'); define('LOGGED_IN_KEY', '*0kP!|VS.K=;#fPMlO DO NOT COPY THESE VALUES +&[%8xF*,18c @'); define('NONCE_KEY', 'fmFPF?UJi&(j-{8=$ - DO NOT COPY THESE VALUES CCZ?Q+_~1ZU~;G'); define('AUTH_SALT', '@qA7f}2utTEFNdnbEa DO NOT COPY THESE VALUES t}Vw+8=K%20s=a'); define('SECURE_AUTH_SALT', '%BW6s+d:7K?-`C%zw4 DO NOT COPY THESE VALUES 70U}PO1ejW+7|8'); define('LOGGED_IN_SALT', '-l>F:-dbcWof%4kKmj DO NOT COPY THESE VALUES 8Ypslin3~d|wLD'); define('NONCE_SALT', '4J(<`4&&F (WiK9K#] DO NOT COPY THESE VALUES ^ZikS`es#Fo:V6');

Copie a saída que você recebeu para a área de transferência e abra o arquivo de configuração no seu editor de texto:

  • nano ~/wordpress/wp-config.php

Encontre a seção que contém os valores fictícios para essas configurações. Será algo parecido com isto:

/wordpress/wp-config.php
. . . define('AUTH_KEY',         'put your unique phrase here'); define('SECURE_AUTH_KEY',  'put your unique phrase here'); define('LOGGED_IN_KEY',    'put your unique phrase here'); define('NONCE_KEY',        'put your unique phrase here'); define('AUTH_SALT',        'put your unique phrase here'); define('SECURE_AUTH_SALT', 'put your unique phrase here'); define('LOGGED_IN_SALT',   'put your unique phrase here'); define('NONCE_SALT',       'put your unique phrase here'); . . . 

Exclua essas linhas e cole os valores que você copiou a partir da linha de comando.

Em seguida, insira as informações de conexão para seu banco de dados remoto. Essas linhas de configuração estão na parte superior do arquivo, logo acima de onde você colou suas chaves. Lembre-se de usar o mesmo endereço IP que você usou no teste de banco de dados remoto anteriormente:

/wordpress/wp-config.php
. . . /** The name of the database for WordPress */ define('DB_NAME', 'wordpress');  /** MySQL database username */ define('DB_USER', 'remotewpuser');  /** MySQL database password */ define('DB_PASSWORD', 'password');  /** MySQL hostname */ define('DB_HOST', 'db_server_ip'); . . . 

E, finalmente, em qualquer lugar do arquivo, adicione a seguinte linha que diz ao WordPress para usar uma conexão SSL para o nosso banco de dados MySQL:

/wordpress/wp-config.php
define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL); 

Salve e feche o arquivo.

Em seguida, copie os arquivos e diretórios encontrados no diretório ~/wordpress para a raiz de documentos do Nginx. Observe que este comando inclui a flag -a para garantir que todas as permissões existentes sejam transferidas:

  • sudo cp -a ~/wordpress/* /var/www/html

Depois disso, a única coisa a fazer é modificar a propriedade do arquivo. Altere a propriedade de todos os arquivos na raiz de documentos para www-data, o usuário padrão do servidor web do Ubuntu:

  • sudo chown -R www-data:www-data /var/www/html

Com isso, o WordPress está instalado e você está pronto para executar sua rotina de configuração baseada em web.

Passo 5 — Configurando o WordPress Através da Interface Web

O WordPress possui um processo de configuração baseado na web. Conforme você avança, ele fará algumas perguntas e instalará todas as tabelas necessárias no seu banco de dados. Aqui, abordaremos as etapas iniciais da configuração do WordPress, que você pode usar como ponto de partida para criar seu próprio site personalizado que usa um back-end de banco de dados remoto.

Navegue até o nome de domínio (ou endereço IP público) associado ao seu servidor web:

http://example.com 

Você verá uma tela de seleção de idioma para o instalador do WordPress. Selecione o idioma apropriado e clique na tela principal de instalação:

WordPress install screen

Depois de enviar suas informações, você precisará fazer login na interface de administração do WordPress usando a conta que você acabou de criar. Você será direcionado para um painel onde poderá personalizar seu novo site WordPress.

Conclusão

Ao seguir este tutorial, você configurou um banco de dados MySQL para aceitar conexões protegidas por SSL a partir de uma instalação remota do WordPress. Os comandos e técnicas usados neste guia são aplicáveis a qualquer aplicação web escrita em qualquer linguagem de programação, mas os detalhes específicos da implementação serão diferentes. Consulte a documentação do banco de dados da aplicação ou linguagem para obter mais informações.

DigitalOcean Community Tutorials

Como Instalar e Usar o Docker no CentOS 7

Introdução

O Docker é um aplicativo que torna simples e fácil executar processos de aplicações em um container, que são como máquinas virtuais, apenas mais portáveis, mais fáceis de usar e mais dependentes do sistema operacional do host. Para uma introdução detalhada aos diferentes componentes de um container Docker, confira O Ecossistema do Docker: Uma Introdução aos Componentes Comuns.

Existem dois métodos para instalar o Docker no CentOS 7. Um método envolve instalá-lo em uma instalação existente do sistema operacional. O outro envolve lançar um servidor com uma ferramenta chamada Docker Machine que instala automaticamente o Docker nele.

Neste tutorial, você aprenderá a instalar e usar o Docker em uma instalação existente do CentOS 7.

Pré-requisitos

Nota: O Docker requer uma versão de 64 bits do CentOS 7, bem como uma versão do kernel igual ou maior que 3.10. O Droplet padrão do CentOS 7 de 64 bits atende a esses requisitos.

Todos os comandos neste tutorial devem ser executados como um usuário não-root. Se o acesso como root for requerido para o comando, ele será precedido pelo sudo. O guia de Configuração Inicial do Servidor com o CentOS 7 explica como adicionar usuários e fornecer a eles o acesso ao sudo.

Passo 1 — Instalando o Docker

O pacote de instalação do Docker disponível no repositório oficial do CentOS 7 pode não ser a versão mais recente. Para obter a versão mais recente e melhor, instale o Docker a partir do repositório oficial do Docker. Esta seção mostra como fazer exatamente isso.

Mas primeiro, vamos atualizar o banco de dados de pacotes:

  • sudo yum check-update

Agora execute este comando. Ele adicionará o repositório oficial do Docker, baixará a versão mais recente do Docker e a instalará:

  • curl -fsSL https://get.docker.com/ | sh

Após a conclusão da instalação, inicie o daemon do Docker:

  • sudo systemctl start docker

Verifique se ele está em execução:

  • sudo systemctl status docker

A saída deve ser semelhante à seguinte, mostrando que o serviço está ativo e em execução:

Output
● docker.service - Docker Application Container Engine Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2016-05-01 06:53:52 CDT; 1 weeks 3 days ago Docs: https://docs.docker.com Main PID: 749 (docker)

Por fim, certifique-se que ele vai iniciar em todas as reinicializações do servidor:

  • sudo systemctl enable docker

A instalação do Docker agora oferece não apenas o serviço Docker (daemon), mas também o utilitário de linha de comando docker ou o cliente Docker. Vamos explorar como usar o comando docker mais adiante neste tutorial.

Passo 2 — Executando Comandos Docker Sem Sudo (Opcional)

Por padrão, executar o comando docker requer privilégios de root — isto é, você tem que prefixar o comando com sudo. Ele também pode ser executado por um usuário no grupo docker, que é criado automaticamente durante a instalação do Docker. Se você tentar executar o comando docker sem prefixá-lo com sudo ou sem estar no grupo docker, você obterá uma saída como esta:

Output
docker: Cannot connect to the Docker daemon. Is the docker daemon running on this host?. See 'docker run --help'.

Se você quiser evitar digitar sudo sempre que executar o comando docker, adicione seu nome de usuário ao grupo docker:

  • sudo usermod -aG docker $ (whoami)

Você precisará sair do Droplet e voltar como o mesmo usuário para ativar essa mudança.

Se você precisar adicionar um usuário ao grupo docker no qual você não está logado, declare este username explicitamente usando:

  • sudo usermod -aG docker username

O restante deste artigo supõe que você esteja executando o comando docker como um usuário do grupo de usuários docker. Se você optar por não fazê-lo, por favor, prefixe os comandos com sudo.

Passo 3 — Usando o Comando Docker

Com o Docker instalado e funcionando, agora é a hora de se familiarizar com o utilitário de linha de comando. O uso do docker consiste em passar uma cadeia de opções e subcomandos seguidos por argumentos. A sintaxe assume este formato:

  • docker [option] [command] [arguments]

Para ver todos os subcomandos disponíveis, digite:

  • docker

A partir do Docker 1.11.1, a lista completa de subcomandos disponíveis inclui:

Output
attach Attach to a running container build Build an image from a Dockerfile commit Create a new image from a container's changes cp Copy files/folders between a container and the local filesystem create Create a new container diff Inspect changes on a container's filesystem events Get real time events from the server exec Run a command in a running container export Export a container's filesystem as a tar archive history Show the history of an image images List images import Import the contents from a tarball to create a filesystem image info Display system-wide information inspect Return low-level information on a container or image kill Kill a running container load Load an image from a tar archive or STDIN login Log in to a Docker registry logout Log out from a Docker registry logs Fetch the logs of a container network Manage Docker networks pause Pause all processes within a container port List port mappings or a specific mapping for the CONTAINER ps List containers pull Pull an image or a repository from a registry push Push an image or a repository to a registry rename Rename a container restart Restart a container rm Remove one or more containers rmi Remove one or more images run Run a command in a new container save Save one or more images to a tar archive search Search the Docker Hub for images start Start one or more stopped containers stats Display a live stream of container(s) resource usage statistics stop Stop a running container tag Tag an image into a repository top Display the running processes of a container unpause Unpause all processes within a container update Update configuration of one or more containers version Show the Docker version information volume Manage Docker volumes wait Block until a container stops, then print its exit code

Para visualizar as opções disponíveis para um comando específico, digite:

  • docker subcomando-docker --help

Para visualizar informações de todo o sistema, use:

  • docker info

Passo 4 — Trabalhando com Imagens Docker

Os containers Docker são executados a partir de imagens Docker. Por padrão, ele extrai essas imagens do Docker Hub, um registro Docker gerenciado pela Docker, a empresa por trás do projeto Docker. Qualquer pessoa pode criar e hospedar suas imagens no Docker Hub, de modo que a maioria das aplicações e distribuições Linux que você precisa para executar containers Docker tem imagens que estão hospedadas no Docker Hub.

Para verificar se você pode acessar e baixar imagens do Docker Hub, digite:

  • docker run hello-world

A saída, que deve incluir o seguinte, deve indicar que o Docker está funcionando corretamente:

Output
Hello from Docker. This message shows that your installation appears to be working correctly. …

Você pode procurar imagens disponíveis no Docker Hub usando o comando docker com o subcomando search. Por exemplo, para procurar a imagem do CentOS, digite:

  • docker search centos

O script rastreará o Docker Hub e retornará uma listagem de todas as imagens cujo nome corresponde à string de pesquisa. Nesse caso, a saída será semelhante a esta:

Output
NAME DESCRIPTION STARS OFFICIAL AUTOMATED centos The official build of CentOS. 2224 [OK] jdeathe/centos-ssh CentOS-6 6.7 x86_64 / CentOS-7 7.2.1511 x8… 22 [OK] jdeathe/centos-ssh-apache-php CentOS-6 6.7 x86_64 / Apache / PHP / PHP M… 17 [OK] million12/centos-supervisor Base CentOS-7 with supervisord launcher, h… 11 [OK] nimmis/java-centos This is docker images of CentOS 7 with dif… 10 [OK] torusware/speedus-centos Always updated official CentOS docker imag… 8 [OK] nickistre/centos-lamp LAMP on centos setup 3 [OK] …

Na coluna OFFICIAL, o OK indica uma imagem criada e suportada pela empresa por trás do projeto. Depois de identificar a imagem que você gostaria de usar, você pode fazer o download dela para o seu computador usando o subcomando pull, assim:

  • docker pull centos

Depois que uma imagem foi baixada, você pode então executar um container usando a imagem baixada com o subcomando run. Se uma imagem não tiver sido baixada quando o docker for executado com o subcomando run, o cliente do Docker primeiro fará o download da imagem e, em seguida, executará um container usando-a:

  • docker run centos

Para ver as imagens que foram baixadas para o seu computador, digite:

  • docker images

A saída deve ser semelhante ao seguinte:

[secondary_lable Output] REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE centos              latest              778a53015523        5 weeks ago         196.7 MB hello-world         latest              94df4f0ce8a4        2 weeks ago         967 B 

Como você verá mais adiante neste tutorial, as imagens que você usa para executar containers podem ser modificadas e usadas para gerar novas imagens, que podem então ser enviadas (push é o termo técnico) para o Docker Hub ou outros registros Docker.

Passo 5 — Executando um Container Docker

O container hello-world que você executou na etapa anterior é um exemplo de um container que é executado e sai após a emissão de uma mensagem de teste. Os containers, no entanto, podem ser muito mais úteis do que isso e podem ser interativos. Afinal, eles são semelhantes às máquinas virtuais, apenas mais fáceis de usar.

Como um exemplo, vamos rodar um container usando a última imagem do CentOS. A combinação das chaves -i e -t fornece a você o acesso interativo ao shell no container:

  • docker run -it centos

Seu prompt de comando deve mudar para refletir o fato de que você agora está trabalhando dentro do container e deve assumir esta forma:

Output
[root@59839a1b7de2 /]#

Importante: Observe o ID do container no prompt de comando. No exemplo acima, ele é 59839a1b7de2.

Agora você pode executar qualquer comando dentro do container. Por exemplo, vamos instalar o servidor MariaDB no container em execução. Não há necessidade de prefixar qualquer comando com o sudo, porque você está operando dentro do container com privilégios de root:

  • yum install mariadb-server

Passo 6 — Fazendo o Commit de Alterações para uma Imagem Docker

Quando você inicia uma imagem Docker, você pode criar, modificar e excluir arquivos da mesma forma que você faz com uma máquina virtual. As alterações que você fizer serão aplicadas apenas a esse container. Você pode iniciá-lo e pará-lo, mas depois de destruí-lo com o comando docker rm, as alterações serão perdidas para sempre.

Esta seção lhe mostra como salvar o estado de um container como uma nova imagem Docker.

Depois de instalar o servidor MariaDB dentro do container CentOS, agora você tem um container executando uma imagem, mas o container é diferente da imagem que você usou para criá-lo.

Para salvar o estado do container como uma nova imagem, primeiro saia dele:

  • exit

Em seguida, confirme ou faça o commit das alterações em uma nova instância de imagem Docker usando o seguinte comando. A chave -m é para a mensagem de commit que ajuda você e outras pessoas a saber quais alterações você fez, enquanto -a é usado para especificar o autor. O ID do container é aquele que você anotou anteriormente no tutorial quando iniciou a sessão Docker interativa. A menos que você tenha criado repositórios adicionais no Docker Hub, o repositório geralmente é seu nome de usuário do Docker Hub:

  • docker commit -m "O que você fez na imagem" -a "Nome do autor" container-id repositório/novo_nome_da_imagem

Por exemplo:

  • docker commit -m "adicionado mariadb-server" -a "Sunday Ogwu-Chinuwa" 59839a1b7de2 finid/centos-mariadb

Nota: Quando você faz o commit de uma imagem, a nova imagem é salva localmente, isto é, no seu computador. Posteriormente neste tutorial, você aprenderá a enviar uma imagem para um registro Docker, como o Docker Hub, para que ela possa ser avaliada e usada por você e por outras pessoas.

Depois que a operação for concluída, listar as imagens Docker agora no seu computador deve mostrar a nova imagem, bem como a antiga da qual ela foi derivada:

  • docker images

A saída deve ser desse tipo:

Output
REPOSITORY TAG IMAGE ID CREATED SIZE finid/centos-mariadb latest 23390430ec73 6 seconds ago 424.6 MB centos latest 778a53015523 5 weeks ago 196.7 MB hello-world latest 94df4f0ce8a4 2 weeks ago 967 B

No exemplo acima, centos-mariadb é a nova imagem, que foi derivada da imagem CentOS existente do Docker Hub. A diferença de tamanho reflete as alterações que foram feitas. E neste exemplo, a mudança foi que o servidor MariaDB foi instalado. Então, da próxima vez que você precisar executar um container usando o CentOS com o servidor MariaDB pré-instalado, basta usar a nova imagem. As imagens também podem ser construídas a partir do que é chamado de Dockerfile. Mas esse é um processo mais complicado e que está bem fora do escopo deste artigo. Vamos explorar isso em um artigo futuro.

Passo 7 — Listando os Containers Docker

Depois de usar o Docker por um tempo, você terá muitos containers ativos (em execução) e inativos no seu computador. Para ver os ativos, use:

  • docker ps

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

Output
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f7c79cc556dd centos "/bin/bash" 3 hours ago Up 3 hours silly_spence

Para visualizar todos os containers — ativos e inativos, passe a ele a chave -a:

  • docker ps -a

Para ver o container mais recente que você criou, utilize a opção -l:

  • docker ps -l

Parar um container em execução ou ativo é tão simples quanto digitar:

  • docker stop container-id

O container-id pode ser encontrado na saída do comando docker ps.

Passo 8 — Enviando Imagens para um Repositório Docker

A próximo passo lógico depois de criar uma nova imagem a partir de uma imagem existente é compartilhá-la com alguns de seus amigos selecionados, o mundo inteiro no Docker Hub ou outro registro Docker ao qual você tem acesso. Para enviar uma imagem para o Docker Hub ou qualquer outro registro Docker, você deve ter uma conta lá.

Esta seção mostra como enviar uma imagem para o Docker Hub.

Para criar uma conta no Docker Hub, registre-se em Docker Hub. Depois, para enviar sua imagem, primeiro faça o login no Docker Hub. Você será solicitado a se autenticar:

  • docker login -u usuário_do_registro_docker

Se você especificou a senha correta, a autenticação deve ser bem-sucedida. Então você pode enviar sua própria imagem usando:

  • docker push usuário_do_registro_docker/nome-da-imagem-docker

Isso levará algum tempo para ser concluído e, quando concluído, a saída será algo assim:

Output
The push refers to a repository [docker.io/finid/centos-mariadb] 670194edfaf5: Pushed 5f70bf18a086: Mounted from library/centos 6a6c96337be1: Mounted from library/centos …

Depois de enviar uma imagem para um registro, ela deve estar listada no painel da sua conta, como mostra a imagem abaixo.

Docker image listing on Docker Hub

Se uma tentativa de envio resultar em um erro desse tipo, provavelmente você não efetuou login:

Output
The push refers to a repository [docker.io/finid/centos-mariadb] e3fbbfb44187: Preparing 5f70bf18a086: Preparing a3b5c80a4eba: Preparing 7f18b442972b: Preparing 3ce512daaf78: Preparing 7aae4540b42d: Waiting unauthorized: authentication required

Faça o login e repita a tentativa de envio.

Conclusão

Há muito mais no Docker do que foi mostrado neste artigo, mas isso deve ser suficiente para você começar a trabalhar com ele no CentOS 7. Como a maioria dos projetos open source, o Docker é construído a partir de uma base de código em rápido desenvolvimento, portanto, crie o hábito de visitar a página do blog do projeto para as informações mais recentes.

Confira também os outros tutoriais do Docker na Comunidade da DigitalOcean.

DigitalOcean Community Tutorials

Como Instalar e Usar o Docker Compose no CentOS 7

Introdução

O Docker é uma ótima ferramenta para automatizar o deployment de aplicações Linux dentro de containers de software, mas para aproveitar realmente ao máximo seu potencial, é melhor se cada componente de sua aplicação for executado em seu próprio container. Para aplicações complexas com muitos componentes, orquestrar todos os containers para iniciar e encerrar juntos (para não mencionar ter que falar uns com os outros) pode rapidamente tornar-se problemático.

A comunidade Docker apareceu com uma solução popular chamada Fig, que permitia usar um único arquivo YAML para orquestrar todos os containers e configurações do Docker. Isso se tornou tão popular que a equipe do Docker decidiu fazer o Docker Compose com base nos fontes do Fig, que agora está obsoleto. O Docker Compose torna mais fácil para os usuários orquestrarem os processos de containers do Docker, incluindo inicialização, encerramento e configuração de links e volumes dentro de containers.

Neste tutorial, você instalará a versão mais recente do Docker Compose para ajudá-lo a gerenciar aplicações de vários containers e explorará os comandos básicos do software.

Conceitos de Docker e Docker Compose

A utilização do Docker Compose requer uma combinação de vários conceitos diferentes do Docker em um, portanto, antes de começarmos, vamos analisar alguns dos vários conceitos envolvidos. Se você já estiver familiarizado com os conceitos do Docker, como volumes, links e port forwarding, você pode querer ir em frente e pular para a próxima seção.

Imagens Docker

Cada container Docker é uma instância local de uma imagem Docker. Você pode pensar em uma imagem Docker como uma instalação completa do Linux. Geralmente, uma instalação mínima contém apenas o mínimo de pacotes necessários para executar a imagem. Essas imagens usam o kernel do sistema host, mas como elas estão rodando dentro de um container Docker e só veem seu próprio sistema de arquivos, é perfeitamente possível executar uma distribuição como o CentOS em um host Ubuntu (ou vice-versa).

A maioria das imagens Docker é distribuída através do Docker Hub, que é mantido pela equipe do Docker. Os projetos open source mais populares têm uma imagem correspondente carregada no Registro Docker, que você pode usar para fazer o deploy do software. Quando possível, é melhor pegar imagens “oficiais”, pois elas são garantidas pela equipe do Docker e seguem as práticas recomendadas do Docker.

Comunicação Entre Imagens Docker

Os containers Docker são isolados da máquina host, o que significa que, por padrão, a máquina host não tem acesso ao sistema de arquivos dentro do container, nem a qualquer meio de comunicação com ele por meio da rede. Isso pode dificultar a configuração e o trabalho com a imagem em execução em um container Docker.

O Docker tem três maneiras principais de contornar isso. O primeiro e mais comum é fazer com que o Docker especifique variáveis de ambiente que serão definidas dentro do container. O código em execução no container Docker verificará os valores dessas variáveis de ambiente na inicialização e os utilizará para se configurar adequadamente.

Outro método comumente usado é um Docker data volume. Os volumes Docker vêm em dois tipos – internos e compartilhados.

Especificar um volume interno significa apenas que, para uma pasta que você especificar para um determinado container Docker, os dados persistirão quando o container for removido. Por exemplo, se você quisesse ter certeza de que seus arquivos de log persistam, você poderia especificar um volume /var/log interno.

Um volume compartilhado mapeia uma pasta dentro de um container Docker para uma pasta na máquina host. Isso permite que você compartilhe arquivos facilmente entre o container Docker e a máquina host.

A terceira maneira de se comunicar com um container Docker é pela rede. O Docker permite a comunicação entre diferentes containers por meio de links, bem como o port forwarding ou encaminhamento de portas, permitindo que você encaminhe portas de dentro do container Docker para portas no servidor host. Por exemplo, você pode criar um link para permitir que os containers do WordPress e do MariaDB se comuniquem entre si e usem o encaminhamento de porta para expor o WordPress ao mundo externo, para que os usuários possam se conectar a ele.

Pré-requisitos

Para seguir este artigo, você precisará do seguinte:

Uma vez que estes requisitos estejam atentidos, você estará pronto para seguir adiante.

Passo 1 — Instalando o Docker Compose

Para obter a versão mais recente, tome conhecimento dos docs do Docker e instale o Docker Compose a partir do binário no repositório GitHub do Docker.

Verifique a release atual e se necessário, atualize-a no comando abaixo:

  • sudo curl -L "https://github.com/docker/compose/releases/download/1.23.2/docker-compose-$ (uname -s)-$ (uname -m)" -o /usr/local/bin/docker-compose

Em seguida, defina as permissões para tornar o binário executável:

  • sudo chmod +x /usr/local/bin/docker-compose

Logo após, verifique se a instalação foi bem-sucedida, checando a versão

  • docker-compose --version

Isso imprimirá a versão que você instalou:

Output
docker-compose version 1.23.2, build 1110ad01

Agora que você tem o Docker Compose instalado, você está pronto para executar um exemplo de “Hello World”.

Passo 2 — Executando um Container com o Docker Compose

O registro público do Docker, o Docker Hub, inclui uma imagem simples “Hello World” para demonstração e teste. Ela ilustra a configuração mínima necessária para executar um container usando o Docker Compose: um arquivo YAML que chama uma única imagem.

Primeiro, crie um diretório para o nosso arquivo YAML:

  • mkdir hello-world

Em seguida, mude para o diretório:

  • cd hello-world

Agora crie o arquivo YAML usando seu editor de texto favorito. Este tutorial usará o vi:

  • vi docker-compose.yml

Entre no modo de inserção, pressionando i, depois coloque o seguinte conteúdo no arquivo:

docker-compose.yml
my-test:   image: hello-world 

A primeira linha fará parte do nome do container. A segunda linha especifica qual imagem usar para criar o container. Quando você executar o comando docker-compose up, ele procurará uma imagem local com o nome especificado, hello-world.

Com isso pronto, pressione ESC para sair do modo de inserção. Digite :x e depois ENTER para salvar e sair do arquivo.

Para procurar manualmente as imagens no seu sistema, use o comando docker images:

  • docker images

Quando não há imagens locais, apenas os cabeçalhos das colunas são exibidos:

Output
REPOSITORY TAG IMAGE ID CREATED SIZE

Agora, ainda no diretório ~/hello-world, execute o seguinte comando para criar o container:

  • docker-compose up

Na primeira vez que executarmos o comando, se não houver uma imagem local chamada hello-world, o Docker Compose vai baixá-la do repositório público do Docker Hub:

Output
Pulling my-test (hello-world:)… latest: Pulling from library/hello-world 1b930d010525: Pull complete . . .

Depois de baixar a imagem, o docker-compose cria um container, anexa e executa o programa hello, que por sua vez confirma que a instalação parece estar funcionando:

Output
. . . Creating helloworld_my-test_1… Attaching to helloworld_my-test_1 my-test_1 | my-test_1 | Hello from Docker. my-test_1 | This message shows that your installation appears to be working correctly. my-test_1 | . . .

Em seguida, imprimirá uma explicação do que ele fez:

Output
. . . my-test_1 | To generate this message, Docker took the following steps: my-test_1 | 1. The Docker client contacted the Docker daemon. my-test_1 | 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. my-test_1 | (amd64) my-test_1 | 3. The Docker daemon created a new container from that image which runs the my-test_1 | executable that produces the output you are currently reading. my-test_1 | 4. The Docker daemon streamed that output to the Docker client, which sent it my-test_1 | to your terminal. . . .

Os containers Docker só são executados enquanto o comando estiver ativo, portanto, assim que o hello terminar a execução, o container finaliza. Conseqüentemente, quando você olha para os processos ativos, os cabeçalhos de coluna aparecerão, mas o container hello-world não será listado porque não está em execução:

  • docker ps
Output
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Use a flag -a para mostrar todos os containers, não apenas os ativos:

  • docker ps -a
Output
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 50a99a0beebd hello-world "/hello" 3 minutes ago Exited (0) 3 minutes ago hello-world_my-test_1

Agora que você testou a execução de um container, é possível explorar alguns dos comandos básicos do Docker Compose.

Passo 3 — Aprendendo os Comandos do Docker Compose

Para começar com o Docker Compose, esta seção irá examinar os comandos gerais que a ferramenta docker-compose suporta.

O comando docker-compose funciona em uma base por diretório. Você pode ter vários grupos de containers do Docker em execução em uma máquina — basta criar um diretório para cada container e um arquivo docker-compose.yml para cada diretório.

Até agora você tem executado o docker-compose up por conta própria, a partir do qual você pode usar o CTRL-C para fechar o container. Isso permite que as mensagens de debug sejam exibidas na janela do terminal. Isso não é o ideal; quando rodando em produção, é mais robusto ter o docker-compose agindo mais como um serviço. Uma maneira simples de fazer isso é adicionar a opção -d quando você fizer um up em sua sessão:

  • docker-compose up -d

O docker-compose agora será executado em segundo plano ou background.

Para mostrar seu grupo de containers Docker (estejam interrompidos ou em execução no momento), use o seguinte comando:

  • docker-compose ps -a

Se um container for interrompido, o State será listado como Exited, conforme mostrado no exemplo a seguir:

Output
Name Command State Ports ------------------------------------------------ hello-world_my-test_1 /hello Exit 0

Um container em execução mostrará Up:

Output
Name Command State Ports --------------------------------------------------------------- nginx_nginx_1 nginx -g daemon off; Up 443/tcp, 80/tcp

Para parar todos os containers Docker em execução para um grupo de aplicações, digite o seguinte comando no mesmo diretório que o arquivo docker-compose.yml que você usou para iniciar o grupo Docker:

  • docker-compose stop

Nota: docker-compose kill também está disponível se você precisar fechar as coisas de maneira forçada.

Em alguns casos, os containers Docker armazenarão suas informações antigas em um volume interno. Se você quiser começar do zero, você pode usar o comando rm para excluir totalmente todos os containers que compõem o seu grupo de containers:

  • docker-compose rm

Se você tentar qualquer um desses comandos a partir de um diretório diferente do diretório que contém um container Docker e um arquivo .yml, ele retornará um erro:

Output
ERROR: Can't find a suitable configuration file in this directory or any parent. Are you in the right directory? Supported filenames: docker-compose.yml, docker-compose.yaml

Esta seção abordou o básico sobre como manipular containers com o Docker Compose. Se você precisasse obter maior controle sobre seus containers, você poderia acessar o sistema de arquivos do container e trabalhar a partir de um prompt de comando dentro de seu container, um processo descrito na próxima seção.

Passo 4 — Acessando o Sistema de Arquivos do Container Docker

Para trabalhar no prompt de comando dentro de um container e acessar seu sistema de arquivos, você pode usar o comando docker exec.

O exemplo “Hello World” sai depois de ser executado, portanto, para testar o docker exec, inicie um container que continuará em execução. Para os fins deste tutorial, use a imagem Nginx do Docker Hub.

Crie um novo diretório chamado nginx e vá até ele:

  • mkdir ~/nginx
  • cd ~/nginx

Em seguida, crie um arquivo docker-compose.yml em seu novo diretório e abra-o em um editor de texto:

  • vi docker-compose.yml

Em seguida, adicione as seguintes linhas ao arquivo:

~/nginx/docker-compose.yml
nginx:   image: nginx 

Salve o arquivo e saia. Inicie o container Nginx como um processo em background com o seguinte comando:

  • docker-compose up -d

O Docker Compose fará o download da imagem Nginx e o container será iniciado em background.

Agora você precisará do CONTAINER ID para o container. Liste todos os containers que estão em execução com o seguinte comando:

  • docker ps

Você verá algo semelhante ao seguinte:

Output of `docker ps`
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b86b6699714c nginx "nginx -g 'daemon of…" 20 seconds ago Up 19 seconds 80/tcp nginx_nginx_1

Se você quisesse fazer uma alteração no sistema de arquivos dentro deste container, você pegaria seu ID (neste exemplo b86b6699714c) e usaria docker exec para iniciar um shell dentro do container:

  • docker exec -it b86b6699714c /bin/bash

A opção -t abre um terminal, e a opção -i o torna interativo. /bin/bash abre um shell bash para o container em execução.

Você verá um prompt bash para o container semelhante a:

root@b86b6699714c:/# 

A partir daqui, você pode trabalhar no prompt de comando dentro do seu container. No entanto, lembre-se de que, a menos que você esteja em um diretório salvo como parte de um volume de dados, suas alterações desaparecerão assim que o container for reiniciado. Além disso, lembre-se de que a maioria das imagens Docker é criada com instalações mínimas do Linux, portanto, alguns dos utilitários e ferramentas de linha de comando aos quais você está acostumado podem não estar presentes.

Conclusão

Agora você instalou o Docker Compose, testou sua instalação executando um exemplo “Hello World” e explorou alguns comandos básicos.

Embora o exemplo “Hello World” tenha confirmado sua instalação, a configuração simples não mostra um dos principais benefícios do Docker Compose — a capacidade de ligar e desligar um grupo de containers Docker ao mesmo tempo. Para ver o poder do Docker Compose em ação, confira How To Secure a Containerized Node.js Application with Nginx, Let’s Encrypt, and Docker Compose e How To Configure a Continuous Integration Testing Environment with Docker and Docker Compose on Ubuntu 16.04. Embora estes tutoriais sejam voltados para o Ubuntu 16.04 e 18.04, os passos podem ser adaptados para o CentOS 7.

DigitalOcean Community Tutorials

Como Instalar o Servidor Web Apache no CentOS 7

Introdução

O servidor HTTP Apache é o servidor web mais utilizado no mundo. Ele fornece muitos recursos poderosos incluindo módulos dinamicamente carregáveis, suporte robusto a mídia, e integração extensiva com outros softwares populares.

Neste guia, você instalará um servidor web Apache com virtual hosts em seu servidor CentOS 7.

Pré-requisitos

Você precisará do seguinte para concluir este guia:

Passo 1 — Instalando o Apache

O Apache está disponível nos repositórios de software padrão do CentOS, o que significa que você pode instalá-lo com o gerenciador de pacotes yum.

Agindo como o usuário não-root, com privilégios sudo configurado nos pré-requisitos, atualize o índice de pacotes local httpd do Apache para refletir as alterações mais recentes do upstream:

  • sudo yum update httpd

Depois que os pacotes forem atualizados, instale o pacote Apache:

  • sudo yum install httpd

Após confirmar a instalação, o yum instalará o Apache e todas as dependências necessárias. Quando a instalação estiver concluída, você estará pronto para iniciar o serviço.

Passo 2 — Verificando seu Servidor Web

O Apache não inicia automaticamente no CentOS depois que a instalação é concluída. Você precisará iniciar o processo do Apache manualmente:

  • sudo systemctl start httpd

Verifique se o serviço está sendo executado com o seguinte comando:

  • sudo systemctl status httpd

Você verá um status active quando o serviço estiver em execução:

Output
Redirecting to /bin/systemctl status httpd.service ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2019-02-20 01:29:08 UTC; 5s ago Docs: man:httpd(8) man:apachectl(8) Main PID: 1290 (httpd) Status: "Processing requests..." CGroup: /system.slice/httpd.service ├─1290 /usr/sbin/httpd -DFOREGROUND ├─1291 /usr/sbin/httpd -DFOREGROUND ├─1292 /usr/sbin/httpd -DFOREGROUND ├─1293 /usr/sbin/httpd -DFOREGROUND ├─1294 /usr/sbin/httpd -DFOREGROUND └─1295 /usr/sbin/httpd -DFOREGROUND ...

Como você pode ver nesta saída, o serviço parece ter sido iniciado com sucesso. No entanto, a melhor maneira de testar isso é solicitar uma página do Apache.

Você pode acessar a página inicial padrão do Apache para confirmar que o software está sendo executado corretamente através do seu endereço IP. Se você não souber o endereço IP do seu servidor, poderá obtê-lo de algumas maneiras diferentes a partir da linha de comando.

Digite isto no prompt de comando do seu servidor:

  • hostname -I

Esse comando exibirá todos os endereços de rede do host, assim você receberá um retorno com alguns endereços IP separados por espaços. Você pode experimentar cada um em seu navegador para ver se eles funcionam.

Alternativamente, você pode usar o curl para solicitar seu IP através do icanhazip.com, que lhe dará seu endereço IPv4 público como visto de outro local na internet:

  • curl -4 icanhazip.com

Quando você tiver o endereço IP do seu servidor, insira-o na barra de endereços do seu navegador:

http://ip_do_seu_servidor 

Você verá a página padrão do Apache do CentOS 7:

Default Apache page for CentOS 7

Esta página indica que o Apache está funcionando corretamente. Ela também inclui algumas informações básicas sobre arquivos importantes do Apache e sobre localizações de diretórios. Agora que o serviço está instalado e em execução, você pode usar diferentes comandos systemctl para gerenciar o serviço.

Passo 3 — Gerenciando o Processo do Apache

Agora que você tem seu servidor web funcionando, vamos passar por alguns comandos básicos de gerenciamento.

Para parar seu servidor web, digite:

  • sudo systemctl stop httpd

Para iniciar o servidor web quando ele estiver parado, digite:

  • sudo systemctl start httpd

Para parar e iniciar o serviço novamente, digite:

  • sudo systemctl restart httpd

Se você estiver simplesmente fazendo alterações de configuração, o Apache pode muita vezes recarregar sem perder conexões. Para fazer isso, use este comando:

  • sudo systemctl reload httpd

Por padrão, o Apache é configurado para iniciar automaticamente quando o servidor é inicializado. Se isso não é o que você deseja, desabilite esse comportamento digitando:

  • sudo systemctl disable httpd

Para reativar o serviço para iniciar na inicialização, digite:

  • sudo systemctl enable httpd

O Apache agora será iniciado automaticamente quando o servidor inicializar novamente.

A configuração padrão do Apache permitirá que seu servidor hospede um único site. Se você planeja hospedar vários domínios em seu servidor, precisará configurar virtual hosts em seu servidor Apache.

Passo 4 — Configurando Virtual Hosts (Recomendado)

Ao utilizar o servidor web Apache, você pode usar virtual hosts (similares aos blocos do servidor no Nginx) para encapsular detalhes de configuração e hospedar mais de um domínio a partir de um único servidor. Neste passo você irá configurar um domínio chamado example.com, mas você deve substituí-lo por seu próprio nome de domínio. Para aprender mais sobre a configuração de um nome de domínio com a DigitalOcean, veja nossa Introdução ao DNS da DigitalOcean.

O Apache no CentOS 7 tem um bloco de servidor ativado por padrão que é configurado para servir documentos a partir do diretório /var/www/html. Apesar disso funcionar bem para um único site, pode ficar difícil se você estiver hospedando vários sites. Em vez de modificar /var/www/html, você irá criar uma estrutura de diretórios dentro de /var/www para o site example.com, deixando /var/www/html no lugar como o diretório padrão a ser servido se uma requisição de cliente não corresponder a nenhum outro site.

Crie o diretório html para example.com como segue, usando a flag -p para criar qualquer diretório pai que for necessário:

  • sudo mkdir -p /var/www/example.com/html

Crie um diretório adicional para armazenar arquivos de log para o site:

  • sudo mkdir -p /var/www/example.com/log

Em seguida, atribua a propriedade do diretório html com a variável de ambiente $ USER:

  • sudo chown -R $ USER:$ USER /var/www/example.com/html

Certifique-se de que seu web root ou pasta raiz para web tenha o conjunto de permissões padrão:

  • sudo chmod -R 755 /var/www

Em seguida, crie uma página de exemplo index.html usando o vi ou seu editor favorito:

  • sudo vi /var/www/example.com/html/index.html

Pressione i para alternar para o modo INSERT e adicione o seguinte exemplo de HTML ao arquivo:

/var/www/example.com/html/index.html
<html>   <head>     <title>Welcome to Example.com!</title>   </head>   <body>     <h1>Success! The example.com virtual host is working!</h1>   </body> </html> 

Salve e feche o arquivo pressionando ESC, digitando :wq e pressionando ENTER.

Com o diretório do seu site e o arquivo de index de exemplo no lugar, você está quase pronto para criar os arquivos do virtual host. Os arquivos do virtual host especificam a configuração de seus sites independentes e informam ao servidor Apache como responder a várias solicitações de domínio.

Antes de criar seus virtual hosts, você precisará criar um diretório sites-available para armazená-los. Você também criará o diretório sites-enabled que informa ao Apache que um virtual host está pronto para servir aos visitantes. O diretório sites-enabled conterá links simbólicos para os virtual hosts que queremos publicar. Crie ambos os diretórios com o seguinte comando:

  • sudo mkdir /etc/httpd/sites-available /etc/httpd/sites-enabled

Em seguida, você dirá ao Apache para procurar por virtual hosts no diretório sites-enabled. Para fazer isso, edite o arquivo de configuração principal do Apache e adicione uma linha declarando um diretório opcional para arquivos de configuração adicionais:

  • sudo vi /etc/httpd/conf/httpd.conf

Adicione esta linha ao final do arquivo:

IncludeOptional sites-enabled/*.conf 

Salve e feche o arquivo quando terminar de adicionar essa linha. Agora que você tem seus diretórios de virtual host no lugar, você criará seu arquivo de virtual host.

Comece criando um novo arquivo no diretório sites-available:

  • sudo vi /etc/httpd/sites-available/example.com.conf

Adicione o seguinte bloco de configuração e altere o domínio example.com para o seu nome de domínio:

/etc/httpd/sites-available/example.com.conf
<VirtualHost *:80>     ServerName www.example.com     ServerAlias example.com     DocumentRoot /var/www/example.com/html     ErrorLog /var/www/example.com/log/error.log     CustomLog /var/www/example.com/log/requests.log combined </VirtualHost> 

Isso dirá ao Apache onde encontrar diretamente a raiz que contém os documentos web publicamente acessíveis. Ele também informa ao Apache onde armazenar logs de erros e de solicitações para esse site específico.

Salve e feche o arquivo quando terminar.

Agora que você criou os arquivos do virtual host, você os habilitará para que o Apache saiba como servi-los aos visitantes. Para fazer isso, crie um link simbólico para cada virtual host no diretório sites-enabled:

  • sudo ln -s /etc/httpd/sites-available/example.com.conf /etc/httpd/sites-enabled/example.com.conf

Seu virtual host agora está configurado e pronto para servir conteúdo. Antes de reiniciar o serviço Apache, vamos garantir que o SELinux tenha as políticas corretas em vigor para seus virtual hosts.

Passo 5 — Ajustando Permissões do SELinux para Virtual Hosts (Recomendado)

O SELinux está configurado para funcionar com a configuração padrão do Apache. Como você configurou um diretório de log personalizado no arquivo de configuração de virtual hosts, você receberá um erro se tentar iniciar o serviço Apache. Para resolver isso, você precisa atualizar as políticas do SELinux para permitir que o Apache grave nos arquivos necessários. O SELinux traz maior segurança ao seu ambiente CentOS 7, portanto, não é recomendado desativar completamente o módulo do kernel.

Existem diferentes maneiras de definir políticas com base nas necessidades do seu ambiente, pois o SELinux permite que você personalize seu nível de segurança. Esta etapa abordará dois métodos de ajuste das políticas do Apache: universalmente e em um diretório específico. Ajustar políticas em diretórios é mais seguro e, portanto, é a abordagem recomendada.

Ajustando Políticas do Apache Universalmente

Definir a política do Apache universalmente dirá ao SELinux para tratar todos os processos do Apache de forma idêntica usando o booleano httpd_unified. Embora essa abordagem seja mais conveniente, ela não fornecerá o mesmo nível de controle que uma abordagem centrada em uma diretiva de arquivo ou diretório.

Execute o seguinte comando para definir uma política universal para o Apache:

  • sudo setsebool -P httpd_unified 1

O comando setsebool altera os valores booleanos do SELinux. A flag -P atualizará o valor de tempo de inicialização, fazendo com que essa mudança persista durante as reinicializações. httpd_unified é o booleano que irá dizer ao SELinux para tratar todos os processos do Apache como do mesmo tipo, então você habilitou-o com um valor de 1.

Ajustando as Políticas do Apache em um Diretório

Configurar individualmente as permissões do SELinux para o diretório /var/www/example.com/log lhe dará mais controle sobre suas políticas do Apache, mas também pode exigir mais manutenção. Como essa opção não está definindo políticas universalmente, você precisará definir manualmente o tipo de contexto para todos os novos diretórios de log especificados em suas configurações de virtual host.

Primeiro, verifique o tipo de contexto que o SELinux deu ao diretório /var/www/example.com/log:

  • sudo ls -dZ /var/www/example.com/log/

Este comando lista e imprime o contexto do SELinux do diretório. Você verá uma saída semelhante à seguinte:

Output
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/example.com/log/

O contexto atual é httpd_sys_content_t, que informa ao SELinux que o processo do Apache só pode ler arquivos criados neste diretório. Neste tutorial, você irá alterar o tipo de contexto do diretório /var/www/example.com/log para httpd_log_t. Esse tipo permitirá ao Apache gerar e agregar arquivos de log da aplicação web:

  • sudo semanage fcontext -a -t httpd_log_t "/var/www/example.com/log(/.*)?"

Em seguida, use o comando restorecon para aplicar essas mudanças e fazer com que elas persistam durante as reinicializações:

  • sudo restorecon -R -v /var/www/example.com/log

A flag -R executa este comando recursivamente, o que significa que ele atualizará quaisquer arquivos existentes para usar o novo contexto. A flag -v imprimirá as mudanças de contexto feitas pelo comando. Você verá a seguinte saída confirmando as alterações:

Output
restorecon reset /var/www/example.com/log context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:httpd_log_t:s0

Você pode listar os contextos mais uma vez para ver as alterações:

  • sudo ls -dZ /var/www/example.com/log/

A saída reflete o tipo de contexto atualizado:

Output
drwxr-xr-x. root root unconfined_u:object_r:httpd_log_t:s0 /var/www/example.com/log

Agora que o diretório /var/www/example.com/log está usando o tipo httpd_log_t, você está pronto para testar sua configuração de virtual host.

Passo 6 — Testando o Virtual Host (Recomendado)

Uma vez que o contexto do SELinux tenha sido atualizado com quaisquer dos métodos, o Apache poderá gravar no diretório /var/www/example.com/log. Agora você pode reiniciar o serviço Apache com sucesso:

  • sudo systemctl restart httpd

Liste o conteúdo do diretório /var/www/example.com/log para ver se o Apache criou os arquivos de log:

  • ls -lZ /var/www/example.com/log

Você verá que o Apache foi capaz de criar os arquivos error.log e requests.log especificados na configuração do virtual host:

Output
-rw-r--r--. 1 root root 0 Feb 26 22:54 error.log -rw-r--r--. 1 root root 0 Feb 26 22:54 requests.log

Agora que você tem seu virtual host configurado e as permissões do SELinux atualizadas, o Apache agora servirá seu nome de domínio. Você pode testar isso navegando até http://example.com, onde você deve ver algo assim:

Success! The example.com virtual host is working!

Isso confirma que seu virtual host foi configurado e está servindo o conteúdo com êxito. Repita os Passos 4 e 5 para criar novos virtual hosts com permissões do SELinux para domínios adicionais.

Conclusão

Neste tutorial, você instalou e gerenciou o servidor web Apache. Agora que você tem seu servidor web instalado, você tem muitas opções para o tipo de conteúdo que você pode servir e as tecnologias que você pode usar para criar uma experiência mais rica.

Se você quiser criar uma pilha ou stack de aplicação mais completa, consulte este artigo sobre como configurar uma pilha LAMP no CentOS 7.

DigitalOcean Community Tutorials