One place for hosting & domains

      Archives hassan latif

      How You Can Enhance DreamShield With a Security Audit Log


      While it can be tempting to install a WordPress security plugin and sign off, the best website security strategies combine various tools to protect both users and content. However, knowing which tools are worth your time can be challenging.

      It’s vital to take a close look at the features your security tools provide and pair them up so that all your bases are covered. For example, you might start with a malware scanning and removal tool such as DreamShield and then enhance it with a security audit log plugin.

      In this post, we’ll explore this exact combination. We’ll start by introducing you to both DreamShield and WordPress security logs. Then we’ll cover three ways this duo can help protect your site. Let’s get started!

      Do More with DreamPress

      DreamPress’ automatic updates and strong security defenses take server management off your hands so you can focus on creating great content.

      A few years ago, we released DreamShield, a security scanning and malware removal tool for DreamHost users. It not only alerts you to vulnerabilities on your WordPress site but also helps you recover after an attack by automatically removing malware and fixing permissions issues.

      The DreamShield information page.

      By using DreamShield, you can keep your site more secure without lifting a finger. Once enabled, DreamShield performs weekly scans for malware and other potential security risks.

      You’ll also receive update notifications to remind you when your WordPress installation, plugins, and themes need to be upgraded to the latest version. These notifications can help you take advantage of security patches for known problems.

      DreamShield is an add-on for DreamHost plans. You can incorporate it into your hosting account for just $3 per month. Considering the price tags on some other big-name WordPress security tools that offer DreamShield’s features, this is a steal (in our humble opinion)!

      The Benefits of Tracking User Actions Within WordPress

      However, no one security tool can do it all. For this reason, you should consider enhancing DreamShield with a security audit log, which sometimes is also called an activity log.  A security audit log is a record of every action taken on your site so you can spot and quickly resolve problems.

      WordPress doesn’t include a security log out of the box. However, you can keep a security log by installing a plugin. WP Security Audit Log is one of the most popular and highly rated.

      The WP Security Audit Log plugin.

      You’ll be able to easily keep track of all the changes made to your WordPress site, including theme and plugin installations and updates, as well as which user made each change. Additionally, you can see each login attempt, including when and where it took place.

      If you spot any activity that seems suspicious, you can log users out remotely with a single click. While all of this may seem overwhelming and hard to track, email notifications can alert you to the most significant changes, and comprehensive monthly reports can provide a detailed overview.

      WP Security Audit Log is available in both free and premium editions. You can download the free version to keep the audit logs or go with WP Security Audit Log Premium to add SMS and email notifications, reports, user sessions management, and much more. Licenses start at $89 per year.

      How You Can Enhance DreamShield With a Security Log (3 Tips)

      While DreamShield and a security log are individually useful for maintaining your WordPress site’s security, they work really well together. Here are three ways a security log can improve DreamShield’s effectiveness.

      1. Monitor Your Logged In Users

      By using a security log, you can easily keep track of who’s logged in to your site, when, and from where.

      Monitoring user login activity with WP Security Audit Log.

      You’ll also be able to see when a non-existent username tries to log in, when a series of unsuccessful logins has taken place, and when there has been a number of failed login attempts. All of these indicate a possible brute force attack.

      Tracking suspicious and failed login attempts with WP Security Audit Log.

      This feature is beneficial for a few reasons. In addition to monitoring for brute force attacks, you can note suspicious behavior — users who are logging in from an unusual IP address or at strange times of the day.

      A security log complements DreamShield’s scanning and malware removing features. You can keep an eye out for suspicious behavior and prevent attacks by logging out and blocking suspicious users.

      While the free version of WP Security Audit Log will allow you to monitor login attempts, you’ll need the premium plugin to log out WordPress users remotely and block them from your site. It also enables you to prevent simultaneous sessions so two people can’t log in to the same account at the same time.

      Be Awesome on the Internet

      Join our monthly newsletter for tips and tricks to build your dream website!

      2. Boost Your Prevention of Malicious Activity

      In addition to monitoring when users log in and out, you can also see when they make changes to your site, such as updating posts and pages or uploading files to your Media Library.

      A file upload event in WP Security Audit Log.

      If users are making unauthorized changes to your site, it could indicate malicious behavior. A user with bad intentions could add spam links to your posts, upload malicious files, or even delete content from your site altogether — stealing hours of hard work.

      While DreamShield’s automated malware removal feature is an excellent way to recover after an attack, it’s always best to avoid a security breach in the first place. By noting unusual changes made to your site, you can stop an attack as or before it’s happening.

      Plus, you’ll know exactly what’s been done to your site and can work to reverse changes not covered by DreamShield such as spam links or deleted content. Our DreamPress plans come with automated backups and one-click restore functionality to help you recover what you’ve lost as well.

      3. Troubleshoot More Efficiently

      Sometimes the trouble with your WordPress site isn’t directly security-related. Compatibility errors following WordPress core, plugin, or theme updates can spell disaster for both you and your users if your site becomes inaccessible.

      Fortunately, since WP Security Audit Log keeps track of each and every update on your site, you can quickly find offending plugins or themes.

      A plugin update in WP Security Audit Log.

      After restoring a backup of your site to undo the changes made by the update, you can get to work on making sure each part of your website plays nicely with the others. This takes all the guesswork out of traditional WordPress troubleshooting.

      Paired with DreamShield’s update notices, a security log can help ensure your website is up-to-date without causing errors. You’ll be able to better protect your site, users, and revenue by keeping vulnerabilities patched up.

      Conclusion

      Securing your WordPress site isn’t something you want to take lightly. Building an effective security strategy should include combining multiple tools to make sure all your bases are covered, and your users and content are protected.

      When it comes to protecting your WordPress site, DreamHost has your back. Add DreamShield to your hosting plan today!



      Source link

      How To Rewrite URLs with mod_rewrite for Apache on Debian 10


      Introduction

      Apache’s mod_rewrite module lets you rewrite URLs in a cleaner fashion, translating human-readable paths into code-friendly query strings. It also lets you rewrite URLs based on conditions.

      An .htaccess file lets you create and apply rewrite rules without accessing server configuration files. By placing the .htaccess file in the root of your web site, you can manage rewrites on a per-site or per-directory basis.

      In this tutorial, you’ll enable mod_rewrite and use .htaccess files to create a basic URL redirection, and then explore a couple of advanced use cases.

      Prerequisites

      To follow this tutorial, you will need:

      Step 1 — Enabling mod_rewrite

      In order for Apache to understand rewrite rules, we first need to activate mod_rewrite. It’s already installed, but it’s disabled on a default Apache installation. Use the a2enmod command to enable the module:

      This will activate the module or alert you that the module is already enabled. To put these changes into effect, restart Apache:

      • sudo systemctl restart apache2

      mod_rewrite is now fully enabled. In the next step we will set up an .htaccess file that we’ll use to define rewrite rules for redirects.

      Step 2 — Setting Up .htaccess

      An .htaccess file allows us to modify our rewrite rules without accessing server configuration files. For this reason, .htaccess is critical to your web application’s security. The period that precedes the filename ensures that the file is hidden.

      Note: Any rules that you can put in an .htaccess file can also be put directly into server configuration files. In fact, the official Apache documentation recommends using server configuration files instead of .htaccess thanks to faster processing times.

      However, in this simple example, the performance increase will be negligible. Additionally, setting rules in .htaccess is convenient, especially with multiple websites on the same server. It does not require a server restart for changes to take effect or root privileges to edit rules, simplifying maintenance and the process of making changes with an unprivileged account. Popular open-source software like WordPress and Joomla rely on .htaccess files to make modifications and additional rules on demand.

      Before you start using .htaccess files, you’ll need to set up and secure a few more settings.

      By default, Apache prohibits using an .htaccess file to apply rewrite rules, so first you need to allow changes to the file. Open the default Apache configuration file using nano or your favorite text editor:

      • sudo nano /etc/apache2/sites-available/000-default.conf

      Inside that file, you will find a <VirtualHost *:80> block starting on the first line. Inside of that block, add the following new block so your configuration file looks like the following. Make sure that all blocks are properly indented:

      /etc/apache2/sites-available/000-default.conf

      <VirtualHost *:80>
          <Directory /var/www/html>
              Options Indexes FollowSymLinks
              AllowOverride All
              Require all granted
          </Directory>
      
          . . .
      </VirtualHost>
      

      Save and close the file. If you used nano, do so by pressing CTRL+X, Y, then ENTER.

      Then, check your configuration:

      • sudo apache2ctl configtest

      If there are no errors, restart Apache to put your changes into effect:

      • sudo systemctl restart apache2

      Now, create an .htaccess file in the web root:

      • sudo nano /var/www/html/.htaccess

      Add this line at the top of the new file to activate the rewrite engine.

      /var/www/html/.htaccess

      RewriteEngine on
      

      Save the file and exit.

      You now have an operational .htaccess file that you can use to govern your web application’s routing rules. In the next step, we will create a sample website file that we’ll use to demonstrate rewrite rules.

      Step 3 — Configuring URL Rewrites

      Here, we will set up a basic URL rewrite which converts pretty URLs into actual paths to pages. Specifically, we will allow users to access http://your_server_ip/about, and display a page called about.html.

      Begin by creating a file named about.html in the web root:

      • sudo nano /var/www/html/about.html

      Copy the following HTML code into the file, then save and close it.

      /var/www/html/about.html

      <html>
          <head>
              <title>About Us</title>
          </head>
          <body>
              <h1>About Us</h1>
          </body>
      </html>
      

      You can access this page at http://your_server_ip/about.html, but notice that if you try to access http://your_server_ip/about, you will see a 404 Not Found error. To access the page using /about instead, we’ll create a rewrite rule.

      All RewriteRules follow this format:

      General RewriteRule structure

      RewriteRule pattern substitution [flags]
      
      • RewriteRule specifies the directive.
      • pattern is a regular expression that matches the desired string from the URL, which is what the viewer types in the browser.
      • substitution is the path to the actual URL, i.e. the path of the file Apache serves.
      • flags are optional parameters that can modify how the rule works.

      Let’s create our URL rewrite rule. Open up the .htaccess file:

      • sudo nano /var/www/html/.htaccess

      After the first line, add the following RewriteRule and save the file:

      /var/www/html/.htaccess

      RewriteEngine on
      RewriteRule ^about$ about.html [NC]
      

      In this case, ^about$ is the pattern, about.html is the substitution, and [NC] is a flag. Our example uses a few characters with special meaning:

      • ^ indicates the start of the URL, after your_server_ip/.
      • $ indicates the end of the URL.
      • about matches the string “about”.
      • about.html is the actual file that the user accesses.
      • [NC] is a flag that makes the rule case insensitive.

      You can now access http://your_server_ip/about in your browser. In fact, with the rule shown above, the following URLs will also point to about.html:

      • http://your_server_ip/about, because of the rule definition.
      • http://your_server_ip/About, because the rule is case insensitive.
      • http://your_server_ip/about.html, because the original filename will always work.

      However, the following will not work:

      • http://your_server_ip/about/, because the rule explicitly states that there may be nothing after about, since the $ character appears after about.
      • http://your_server_ip/contact, because it won’t match the about string in the rule.

      You now have an operational .htaccess file with a basic rule that you can modify and extend to your needs. In the following sections, we will show two additional examples of commonly used directives.

      Example 1 — Simplifying Query Strings with RewriteRule

      Web applications often make use of query strings, which are appended to a URL using a question mark (?) after the address. Separate parameters are delimited using an ampersand (&). Query strings may be used for passing additional data between individual application pages.

      For example, a search result page written in PHP may use a URL like http://example.com/results.php?item=shirt&season=summer. In this example, two additional parameters are passed to the imaginary result.php application script: item, with the value shirt, and season with the value summer. The application may use the query string information to build the right page for the visitor.

      Apache rewrite rules are often employed to simplify such long and unpleasant links as the example above into friendly URLs that are easier to type and interpret visually. In this example, we would like to simplify the above link to become http://example.com/shirt/summer. The shirt and summer parameter values are still in the address, but without the query string and script name.

      Here’s one rule to implement this:

      Simple substition

      RewriteRule ^shirt/summer$ results.php?item=shirt&season=summer [QSA]
      

      The shirt/summer is explicitly matched in the requested address and Apache is told to serve results.php?item=shirt&season=summer instead.

      The [QSA] flags are commonly used in rewrite rules. They tell Apache to append any additional query string to the served URL, so if the visitor types http://example.com/shirt/summer?page=2 the server will respond with results.php?item=shirt&season=summer&page=2. Without it, the additional query string would get discarded.

      While this method achieves the desired effect, both the item name and season are hardcoded into the rule. This means the rule will not work for any other items, like pants, or seasons, like winter.

      To make the rule more generic, we can use regular expressions to match parts of the original address and use those parts in a substitution pattern. The modified rule will then look like this:

      Simple substition

      RewriteRule ^([A-Za-z0-9]+)/(summer|winter|fall|spring) results.php?item=$1&season=$2 [QSA]
      

      The first regular expression group in parenthesis matches a string containing alphanumeric characters and numbers like shirt or pants and saves the matched fragment as the $1 variable. The second regular expression group in parentheses matches exactly summer, winter, fall, or spring, and similarly saves the matched fragment as $2.

      The matched fragments are then used in the resulting URL in item and season variables instead of the hardcoded shirt and summer values we used before.

      The above will convert, for example, http://example.com/pants/summer into http://example.com/results.php?item=pants&season=summer. This example is also future proof, allowing multiple items and seasons to be correctly rewritten using a single rule.

      Example 2 — Adding Conditions with Logic Using RewriteConds

      Rewrite rules are not necessarily always evaluated one by one without any limitations. The RewriteCond directive lets us add conditions to our rewrite rules to control when the rules will be processed. All RewriteConds abide by the following format:

      General RewriteCond structure

      RewriteCond TestString Condition [Flags]
      
      • RewriteCond specifies the RewriteCond directive.
      • TestString is the string to test against.
      • Condition is the pattern or condition to match.
      • Flags are optional parameters that may modify the condition and evaluation rules.

      If a RewriteCond evaluates to true, the next RewriteRule will be considered. If it doesn’t, the rule will be discarded. Multiple RewriteConds may be used one after another, though all must evaluate to true for the next rule to be considered.

      As an example, let’s assume you would like to redirect all requests to non-existent files or directories on your site back to the home page instead of showing the standard 404 Not Found error page. This can be achieved with following conditions rules:

      Redirect all requests to non-existent files and directories to home page

      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteRule . /
      

      With the above:

      • %{REQUEST_FILENAME} is the string to check. In this case, it’s the requested filename, which is a system variable available for every request.
      • -f is a built-in condition which verifies if the requested name exists on disk and is a file. The ! is a negation operator. Combined, !-f evaluates to true only if the specified name does not exist or is not a file.
      • Similarly, !-d evaluates to true only if the specified name does not exist or is not a directory.

      The RewriteRule on the final line will come into effect only for requests to non-existent files or directories. The RewriteRule itself is very simple and redirects every request to the / website root.

      mod_rewrite lets you create human-readable URLs. In this tutorial, you learned how to use the RewriteRule directive to redirect URLs, including ones with query strings. You also learned how to conditionally redirect URLs using the RewriteCond directive.

      If you’d like to learn more about mod_rewrite, take a look at Apache’s mod_rewrite Introduction and Apache’s official documentation for mod_rewrite.



      Source link

      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

      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”.

      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:

      Em seguida, mude para o diretório:

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

      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:

      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:

      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:

      Output

      CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

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

      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:

      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:

      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:

      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:

      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:

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

      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:

      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:

      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.



      Source link