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
!
Obtenha todos os seus aplicativos, banco de dados e Sites WordPress on-line e sob o mesmo teto. Nossa plataforma de nuvens de alto desempenho e repleta de recursos inclui:
- Fácil configuração e gerenciamento no painel MyKinsta
- Suporte especializado 24/7
- O melhor hardware e rede do Google Cloud Platform, alimentado por Kubernetes para a máxima escalabilidade
- Integração Cloudflare de nível empresarial para velocidade e segurança
- Audiência global com centros de dados de até 35 e 275 PoPs no mundo todo
Comece agora com uma avaliação gratuita do nosso Hospedagem de Aplicativos ou Hospedagem de Banco de Dados. Explore nossos planos ou entre em contato com as vendas para encontrar o que melhor se adapta às suas necessidades.
Deixe uma resposta