Como fazer amigos PHPstorm, xDebug e ramificações remotas compiladas pelo Docker? Muito simples ...

Bom dia, Habr!

Há um ano, meu processo de depuração de código no PHP consistia em duas linhas:

var_dump($variable); die(); 

De tempos em tempos, é claro, eu precisava usar construções mais "complexas":

 console.log(data); 

 echo json_encode($variable, JSON_UNESCAPED_UNICODE); exit(); 

Não, o que você é! Eu sabia - em nosso tempo, não é apropriado que um programador cultural faça isso


Mas, honestamente, eu sempre tive medo do que não entendi. Incluindo impressoras xDebug, especialmente como configurar tudo isso. Um belo dia, consegui fazê-lo no meu carro e em um projeto local - não havia limite para a alegria. Muitos meses depois, me deparei com um novo problema, como depurar no PHPstorm via xDebug, se o projeto for construído remotamente pelo docker via CI.

Se você, como eu, tiver dificuldade em configurar coisas diferentes, seja bem-vindo ao gato, falarei sobre minha experiência na criação de um ambiente de depuração com palavras assustadoras como Docker, xDebug, CI.

Para quem não gosta de água e quer ir diretamente para a essência do cenário.

Por que você deve se afastar dos métodos de depuração bolorentos e mudar para as tecnologias adequadas?

Enganei um pouco o gato, estava envolvido na depuração artesanal, não apenas porque tinha medo de configurar alguma coisa, e não porque era muito estúpido, mas simplesmente porque não precisava de algo mais conveniente. Na maioria das vezes, eu trabalhava em projetos localmente no meu computador bastante poderoso, e as tarefas não eram tão complicadas que o processo de depuração começou a ocupar uma posição bastante significativa.

Em algum momento, percebi por mim mesmo que estava desconfortável e tentei fazer amigos xDebug e PHPstorm ao trabalhar em um projeto local. O problema é que a maioria das documentações e guias que eu achei sugerem que a pessoa que os lê é bastante versada na área de assunto e entende tudo, no meu caso, esse não foi o caso e passei 4-5 na minha primeira instalação do xDebug horas em duas horas. Era moral bastante difícil, me senti infinitamente idiota. No entanto, acabou por configurar, tudo funcionou!

Sim, tornou-se mais conveniente, localmente, em casa, mas no trabalho principal eu fiz os sites remotamente e, na maioria das vezes, não consegui descarregar o site localmente (devido a uma máquina fraca ou processo de implantação inconveniente) ou afetar as configurações do servidor devido a a hospedagem, portanto, tornou as edições "ao vivo" e a depuração envolvidas no print_r com comentários em html (naquele trabalho era "normal", embora não se orgulhasse dessa experiência).



No entanto, há três meses, mudei para uma empresa mais fria e comecei a me envolver em um projeto realmente sério com uma carga alta. E aqui muita coisa mudou para mim. O processo de infraestrutura e desenvolvimento é aproximadamente o seguinte: existe um servidor GitLab, cada projeto tem seu próprio repositório, as tarefas são enviadas ao Jira, você cria uma filial por números de tarefas, ao criar uma filial usando o CI, sua própria sandbox com o site onde você trabalha silenciosamente é criada automaticamente, a cada push remontar a ramificação; no final do trabalho que você fornece à revisão de código, despeje a ramificação no mestre.

Tudo é legal, exceto por um MAS, cada reconstrução de um ramo no meu caso leva cerca de 10 segundos. No processo de desenvolvimento em si, esse é um momento insignificante, já que já passei do estágio em que tive que verificar a operacionalidade do código em quase todas as linhas devido à incerteza e à pouca experiência. No entanto, quando mudei para a depuração, esses 10 segundos começaram a desempenhar um papel tangível. O processo dessa depuração teve a seguinte aparência:

• Adicione 2 linhas
• Pushu commit
• Eu espero 10 segundos
• Verifique, veja o que há de errado
• Repetir

De acordo com estimativas aproximadas, um ramo pronto para mesclagem tinha aproximadamente 20% de confirmações úteis e 80% de confirmações de depuração. Suponha que eu terminei o trabalho em uma ramificação com 300 confirmações, das quais 240 confirmações basicamente consumiram apenas 40 minutos do meu tempo de trabalho (e esse é apenas o tempo de espera para a montagem da ramificação, sem levar em consideração os segundos que somam minutos, para adicionar duas linhas e exclua-os).



Em algum momento, eu estava cansado disso e decidi configurar o xDebug para tornar o processo de depuração mais barato. Infelizmente, meus colegas atuais não usaram essa tecnologia (estou esperando uma piada sobre "Eu tenho uma empresa legal onde ninguém usa xDebug") ou não sabiam / não se lembravam de como fazer amizade com o xDebug IDE quando a filial indo remotamente via CI e, como nunca desenvolvi DevOps e, como mencionei acima, o processo de criação de algo é um processo doloroso para mim, levou cerca de 6 horas de tempo puro para finalmente funcionar e entendi o processo, e isso seria conveniente o suficiente.

Processo de instalação

Não entrarei em detalhes sobre como fixar a CI, o Docker, em geral, como montar a infraestrutura, presume-se que tudo isso esteja feito e o que resta é configurar o seu ambiente pessoal.

Digamos que nosso repositório tenha algo como esta estrutura:



Primeiro precisamos verificar se o próprio xDebug está na imagem atual, para isso você pode usar o phpinfo ();

Se o xDebug já estiver incluído na montagem - tudo bem, se não estiver, verifique esta fonte , o que me ajudou diretamente na instalação em si, no entanto, eu fui um pouco diferente.

Configurar o php.ini

Para que tudo funcione no final, duas configurações de xDebug são importantes para nós:

• xdebug.remote_enable
• xdebug.remote_host

Na montagem final da ramificação remota, remote_enable deve estar ativado e, em remote_host, o IP do seu computador na rede deve ser atribuído. Vamos incluir essas configurações em nossa compilação.

Primeiro, você precisa descobrir onde as configurações do php estão armazenadas, elas podem ser localizadas em /usr/local/etc/php/conf.d/php.ini ou o próprio arquivo .ini pode ter um nome diferente, no meu caso, é / usr / local / etc / php / conf.d / php-settings.ini . Você pode descobrir nas configurações da imagem coletada.

Criamos nossas configurações adicionais em nosso ramo através do mesmo arquivo php-settings.ini e o colocamos em ./build_env/php/php-settings.ini
Escrevemos nele 2 das configurações acima:
xdebug.remote_enable = on
xdebug.remote_host = IP...

Em seguida, precisamos adicionar esse arquivo às configurações de imagem "pai". Eu faço isso através dos volumes adicionando a linha a ./build_env/docker-compose/docker-compose.tmpl:
- ${PROJECT_DIR}/build_env/php/php-settings.ini:/usr/local/etc/php/conf.d/php-settings.ini

Isto é como o docker-compose.tmpl se parece no meu projeto:



Na próxima vez que você criar o ramo, poderá verificar se as novas configurações estão vinculadas pelo mesmo phpinfo (); se sim - excelente, se não - você está sem sorte e terá que seguir o mesmo caminho que fiz na primeira vez :(

Personalizando mapeamentos no PHPstorm

Em seguida, você precisa configurar o próprio PHPstorm. Decidi não usar o DBgp Proxy, para não configurar sempre os mapeamentos no pop-up. No meu caso, eu uso um modelo de servidor que conterá os mapeamentos necessários.

Vá para Configurações / Preferências | Idiomas e estruturas | Php | Servidores

1. Crie um modelo de servidor
2. Nome: FILIAL
3. host: any, não afeta
4. porta: qualquer, não afeta
5. Depurador: xDebug
6. Coloque um daw em Use mapeamentos de caminho
7. Colocamos os mapeamentos apropriados; as pastas locais de trabalho devem corresponder às pastas no servidor em que as ramificações coletadas estão localizadas; no meu caso, as compilações coletadas estão na pasta / var / www / builds / your_namespace / your_project / your_branch

Salvamos essas configurações e as alteramos toda vez que trabalhamos com uma nova ramificação. Por exemplo, se hoje eu trabalho com a ramificação web-2233, alterarei o mapeamento para / var / www / builds / build_path / web-2233

Adicione uma nova variável de ambiente para que o IDE puxe automaticamente os mapeamentos

Agora, um ponto bastante importante e não o mais óbvio. Quando iniciamos a depuração, o PHPstorm precisa entender quais arquivos locais correspondem aos arquivos no servidor remoto. Se o servidor não forneceu uma instalação específica, aparecerá uma janela pop-up na qual você precisará mapear manualmente os caminhos. Para que o PHPstorm obtenha imediatamente mapeamentos de um servidor com o nome BRANCH, você precisa adicionar a variável de ambiente PHP_IDE_CONFIG ao nosso assembly

Em ./build_env/docker-compose/docker-compose.tmpl, crie uma nova variável de ambiente no ambiente:
PHP_IDE_CONFIG: ${PHP_IDE_CONFIG}



Em .gitlab-ci.yml, definimos esta variável:
- export PHP_IDE_CONFIG="serverName=BRANCH"

Feito!

Não precisamos de extensões do navegador, não precisamos passar o URL XDEBUG_SESSION_START = IDE_KEY para obter parâmetros, não precisamos adicionar configurações adicionais.

Basta ligar a escuta e atualize a página do site, assim que encontrarmos o primeiro ponto de interrupção, o aplicativo será interrompido



Obrigado pela atenção, espero que este artigo seja útil e que alguém economize tempo sem pisar no mesmo rake que eu :)

Fontes que eu usei durante a configuração inicial:
https://gist.github.com/chadrien/c90927ec2d160ffea9c4
https://confluence.jetbrains.com/display/PhpStorm/Docker+Support+in+PhpStorm#DockerSupportinPhpStorm-DebuggingthePHPwebapplicationrunningintheDockercontainer