Como usar Bedrocks e Trellis na Kinsta (Desenvolvimento WordPress)

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

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.

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.

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.

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!