Este é um artigo para todos os desenvolvedores de WordPress que estão por aí!

Hoje vamos explicar como usar e integrar Bedrock e Trellis na Kinsta.

aso você nunca ouviu falar dessas duas ferramentas antes, também vamos apresentá-las e, esperamos, ajudar a explicar porque você gostaria de usá-las em vez de uma configuração tradicional.

Bedrock e Trellis

Tanto Bedrock como Trellis existem para facilitar o desenvolvimento, manutenção e implementação de sites WordPress.

  • Bedrock oferece uma maneira alternativa de gerenciar sua instalação do WordPress com uma estrutura de pastas melhorada, ferramentas de desenvolvimento modernas e maior segurança.
  • Trellis trabalha com Bedrock para criar ambientes de teste com Vagrant juntamente com deploys de um comando.

A principal razão para usar o Bedrock é para obter uma dependência adequada e gerenciamento de pacotes para um projeto WordPress. Você já deve estar familiarizado com npm para JavaScript ou Bundler para Ruby. O PHP não é diferente, e seu equivalente é Composer.

Embora o uso de um gerenciador de pacotes seja comum, ele é menos comum para o próprio WordPress, pois o WordPress já tem seu próprio conceito para plugins. Bedrock integra o Composer para gerenciar plugins, temas e até mesmo o próprio núcleo do WordPress como dependências.

Trellis é uma ferramenta para criar facilmente servidores de teste e produção para hospedar sites WordPress. Foi especificamente criado para trabalhar também com sites baseados em Bedrock. O caso de uso padrão do Trellis é utilizá-la para desenvolvimento com Vagrant e também na produção para obter paridade entre esses dois ambientes.

Este artigo explica um caso de uso ligeiramente diferente: Trellis para o seu servidor de desenvolvimento e Kinsta para o seu servidor de produção (e/ou teste).

Por que usar Kinsta sobre uma Trellis VPS provisionada? Porque às vezes você quer pagar alguém para administrar o servidor em vez de fazê-lo você mesmo (especialmente se você tem muitos clientes). Kinsta também facilita o escalonamento sem ter que lidar com múltiplos servidores, balanceadores de carregamento e uploads de nuvens.

Muitos hospedagens WordPress não são muito amigáveis ao desenvolvimento e não oferecem acesso SSH e Composer ou integração WP-CLI, que são requisitos para usar Trellis e Bedrock. Felizmente, a Kinsta oferece acesso SSH em todos os seus planos de hospedagem, do Starter ao Enterprise, o que torna tudo isso possível. Eles também podem modificar o caminho de raiz para uma funcionalidade adequada.

Bedrock vs WordPress Normal

Você pode estar se perguntando porque você usaria Bedrock em vez de uma instalação tradicional do WordPress. A razão é que Bedrock é construído especificamente com o moderno desenvolvedor web em mente:

  • Arquivos de configuração específicos do ambiente, armazenados fora da raiz da web pública
  • Variáveis de ambiente para separar a configuração do código em um único arquivo .env
  • Maior segurança ao limitar o acesso a arquivos não-web com senhas de criptografia de hastes
  • Diretório de conteúdo wp personalizado chamado app
  • Compositor para gerenciar WordPress, plugins, temas e outras dependências do PHP
  • .gitignore que exclui o núcleo do WordPress, plugins e uploads

Raspberry Pi, Snopes, JetBlue, e mais, confie no Bedrock para alimentar seus sites WordPress.

Vamos dar uma olhada nas duas estruturas de pastas lado a lado:

Bedrock vs WordPress
Bedrock vs WordPress

Bedrock leva a instalação do WordPress em um subdiretório para o próximo nível. Grande parte da filosofia por trás do Bedrock é inspirada na metodologia do aplicativo Twelve-Factor App, incluindo a versão específica do WordPress.

Configuração do Trellis para Kinsta

Primeiro, certifique-se de que suas chaves SSH públicas são adicionadas ao painel MyKinsta.

A Trellis pode ser enviada para Kinsta com apenas algumas atualizações. Como Kinsta fornece tudo do ponto de vista do servidor web, o provisionamento dos seus ambientes de teste e produção não se aplica.

O comando único em Trellis trabalha com Kinsta com um pouco de configuração. Uma vez configurado, você será capaz de implantar seus sites WordPress executando o playbook no Trellis:

ansible-playbook deploy.yml -e env=staging -e site=example.com --limit=kinsta_staging

Traga seu painel do MyKinsta e navegue até o site WordPress que você está configurando com Bedrock e Trellis, com seu editor de código aberto para o diretório trellis do seu projeto.

Primeiro edite trellis/ansible.cfg para adicionar o seguinte em [defaults] no topo:

forks = 3
host_key_checking = False

Configuração de teste

Certifique-se de que o trellis/group_vars/staging/wordpress_sites.yml está configurado com o canonical apropriado para o seu local de teste:

wordpress_sites:
  example.com:
    site_hosts:
      - canonical: staging-example.kinsta.com

Em seguida, abra trellis/group_vars/staging/main.yml e adicione o seguinte ao final do arquivo:

project_root: /www/example_123/public
www_root: /www/example_123/public
web_user: example
web_group: www-data

Substitua o caminho project_root e www_root pelo caminho correto fornecido no painel MyKinsta para o seu ambiente de teste da Kinsta.

Encontre sua public root em MyKinsta.
Onde encontrar o root público no MyKinsta.

Em seguida, abra trellis/group_vars/staging/vault.yml para edição executando ansible-vault edit group_vars/staging/vault.yml.

Precisamos de adicionar db_user, db_name, e db_password para env. Você pode encontrar os valores para estes na tela principal de informações do seu site no painel do MyKinsta.

SFTP e credenciais de banco de dados em MyKinsta.
SFTP e credenciais do banco de dados no MyKinsta.
vault_wordpress_sites:
  example.com:
    env:
      db_user: "example"
      db_name: "example"
      db_password: "xxxxxxxxxxxxxxx"
      # Generate your keys here: https://roots.io/salts.html
      auth_key: ""
      secure_auth_key: ""
      logged_in_key: ""
      nonce_key: ""
      auth_salt: ""
      secure_auth_salt: ""
      logged_in_salt: ""
      nonce_salt: ""

Finalmente, abra a trellis/hosts/staging e substitua o conteúdo por:

kinsta_staging ansible_host=104.154.94.123 ansible_ssh_port=12345 ansible_ssh_extra_args='-o StrictHostKeyChecking=no'

[web]
kinsta_staging

[staging]
kinsta_staging

Certifique-se de que o host e a porta SSH correspondem ao que está listado no painel do MyKinsta.

Detalhes do host SFTP e da porta para o seu ambiente de teste.
Detalhes do host SFTP e da porta para o seu ambiente de teste.

Configuração de produção

Agora, vamos repetir o mesmo processo acima para o ambiente de produção. Certifique-se de alternar para o seu ambiente de produção “ao vivo” no painel do MyKinsta.

Mude para seu ambiente de produção (ao vivo) no MyKinsta.
Mude para seu ambiente de produção (ao vivo) no MyKinsta.

Abra trellis/group_vars/production/main.yml e adicione o seguinte ao final do arquivo:

project_root: /www/example_123/public
www_root: /www/example_123/public
web_user: example
web_group: www-data

Certifique-se de substituir os caminhos project_root e wwww_root pelos caminhos corretos fornecidos no painel MyKinsta para o seu ambiente de produção (ao vivo).

Em seguida, abra trellis/group_vars/production/vault.yml para edição executando ansible-vault edit group_vars/production/vault.yml:

vault_wordpress_sites:
  example.com:
    env:
      db_user: "example"
      db_name: "example"
      db_password: "xxxxxxxxxxxxxxx"
      # Generate your keys here: https://roots.io/salts.html
      auth_key: ""
      secure_auth_key: ""
      logged_in_key: ""
      nonce_key: ""
      auth_salt: ""
      secure_auth_salt: ""
      logged_in_salt: ""
      nonce_salt: ""

Finalmente, abra a trellis/hosts/production e substitua o conteúdo por este:

kinsta_production ansible_host=104.154.94.123 ansible_ssh_port=12345 ansible_ssh_extra_args='-o StrictHostKeyChecking=no'

[web]
kinsta_production

[production]
kinsta_production

Modificando as tarefas de Deploy

Trellis deploys tenta recarregar o php-fpm, que precisamos remover da tentativa de rodar nos servidores da Kinsta. Também precisamos de ativar a limpeza do cache da Kinsta num destacamento.

Abra trellis/roles/deploy/hooks/finalize-after.yml e rolar para o fundo. Remova a última tarefa para Reload php-fpm e adicione o seguinte:

- name: Clear Kinsta cache
  uri:
    url: "{{ site_env.wp_home }}/ask-support-rep/"
    method: GET

Substitua ask-support-rep acima após pedir a um representante de suporte Kinsta para limpar o cache no seu site.

Opcional: Instalando dependências do Composer

Se você estiver recebendo uma tela que lhe diz para executar a ‘Instalação do Composer’, adicione o seguinte logo antes do código “Clear Kinsta cache” acima:

- name: Install Composer dependencies
composer:
command: install
working_dir: >/www/example123/public/final-path

O /final-path pode variar de acordo com as configurações do seu Bedrock/Trellis.

Adicionando kinsta-mu-plugins ao Bedrock

Os sites bedrock vêm com mu-plugins instalados automaticamente, mas, você precisará instalar o plugin Kinsta MU trazendo o pacote kinsta-mu-plugins. Este plugin (que é instalado por padrão quando você cria um site WordPress através do MyKinsta) trata de coisas como o cache de páginas completa e a integração Kinsta CDN.

Abra o site/composer.json e adicione o seguinte na array repositories:

{
  "type": "package",
  "package": {
    "name": "kinsta/kinsta-mu-plugins",
    "type": "wordpress-muplugin",
    "version": "2.3.3",
    "dist": {
      "url": "https://kinsta.com/kinsta-tools/kinsta-mu-plugins.zip",
      "type": "zip"
    }
  }
}

Em seguida, execute o seguinte a partir do seu diretório Bedrock/site (ou especifique os plugins kinsta/kinsta-mu como um requisito em seu arquivo composer.json:

composer require kinsta/kinsta-mu-plugins:2.3.3

As seguintes constantes podem ser necessárias para corrigir problemas com caminhos CDN e URL de ativos de plugins compartilhados. Adicione o seguinte código ao arquivo de configuração do seu site (bedrock/config/application.php em sites bedrock):

/**
 * Kinsta CDN fix for Bedrock
 */
define('KINSTA_CDN_USERDIRS', 'app');

/**
 * Fix Kinsta MU Plugins URL path with Bedrock
 */
$mu_plugins_url = Config::get('WP_CONTENT_URL') . '/mu-plugins';
define('KINSTAMU_CUSTOM_MUPLUGIN_URL', "{$mu_plugins_url}/kinsta-mu-plugins");

Para mais informações, incluindo como atualizar o plugin, consulte nosso guia para o plugin Kinsta MU.

Passos finais com o suporte da Kinsta

A última coisa que você precisa fazer é informar a Kinsta sobre o que deve ser a raiz do documento. Entre no MyKinsta e peça à equipe de suporte para que a raiz do seu documento seja atualizada para o public/current/web.

Caso você ainda não obteve a URL clara do cache antes, peça também ao seu representante de suporte para isso, e certifique-se de que trellis/roles/deploy/hoks/finalize-after.yml seja atualizado com a URL correta para limpar o cache da Kinsta em um deploy bem-sucedido.

Uma vez que esta mudança tenha sido feita, você conseguirá executar o Deploy tanto no seu ambiente de teste quanto no de produção com uma única linha:

# Deploy staging
ansible-playbook deploy.yml -e env=staging -e site=example.com --limit=kinsta_staging

# Deploy production
ansible-playbook deploy.yml -e env=production -e site=example.com --limit=kinsta_production

Melhor ainda… configurar um serviço de integração contínua, como o CircleCI, para executar automaticamente o deploy para você quando você se compromete a staging ou master!

Ben Word

Ben Word é um desenvolvedor web e designer de interação. Ele é o fundador da Roots, uma organização de código aberto que cria ferramentas para ajudar os desenvolvedores de WordPress a construir sites melhores.