AWS Elastic Beanstalk utilizando PHP con repositorys de compositores privados

¿Cómo utilizo los repositorys de compositores privados al implementar con Amazon AWS Elastic Beanstalk en un entorno PHP? Específicamente utilizando GitHub (estilo de preguntas y respuestas, respuesta siguiente)

Necesitábamos usar una biblioteca privada para uno de nuestros proyectos de PHP que estábamos implementando a través de Elastic Beanstalk (EB) de AWS. Esta biblioteca privada está alojada en GitHub, aunque el alojamiento similar de git (su propio server, BitBucket, etc.) probablemente tenga una authentication similar y podría usar esta solución para la implementación.

Usamos las cnetworkingenciales de SSH para acceder al repository privado de git. Como usamos GitHub, utilizamos las Llaves de implementación de GitHub ( https://help.github.com/articles/managing-deploy-keys#deploy-keys ) Estas keys permiten el acceso de solo lectura a un repository específico, que es perfecto para nuestro necesariamente. Evalúe la mejor solución para sus necesidades, GitHub tiene excelentes pros y contras para cada método.

Nuestra solución elegida incorpora la key de implementación con el repository. Esto es un poco un agujero de security. Estamos tratando con todos los repos privados, con (idealmente) serveres seguros, pero esto todavía representa un pequeño riesgo para la security.

Todo esto terminó siendo un poco complicado con la forma en que se implementa la stack de PHP con Elastic Beanstalk, composer.json se estaba ejecutando automáticamente demasiado pronto y las keys no estaban en su lugar de antemano. Encontramos una solución.

Esto supone que ya tiene su configuration de implementación, pero simplemente está atascado en la implementación de keys. Usamos las herramientas eb cli provistas por AWS (eb init, eb branch, eb start, etc.) para poner en marcha las cosas, así como los git hooks, git aws.push para implementar.

Una vez que tenemos nuestras Llaves de implementación, podemos agregar nuestra biblioteca a nuestro file composer.json usando la dirección SSH:

{ ... "require": { "repository/project": ">=1.0.0" }, ... "repositories": [ { "type": "git", "url": "git@github.com:repository/project.git" } ] } 

Configure su .gitignore para que el file composer.lock se confirme y en su repository, así como en la carpeta del proveedor sin sus contenidos:

 [remove composer.lock from file if it exists] vendor/* 

Preferimos mantener el file composer.lock en el repository de todos modos, ya que se bloquea en la versión utilizada en la testing. Cuando nos movemos a un entorno de producción, nos aseguramos de que la aplicación se ejecute con las mismas bibliotecas en las que probamos. Se requiere la carpeta del proveedor para engañar a EB para que no ejecute automáticamente el process de installation de composer.phar. Necesitamos que espere hasta que tengamos las keys ssh en su lugar.

Configuración de las keys: No pude encontrar una buena manera de afiliar la key y aceptar github.com como un known_host a través de scripts. Terminé SSHing en el server administrado EB con el software medio desplegado, agregué los files key id_rsa e id_rsa.pub a ~ root / .ssh / (con 400 perms ¡acuérdate!) Y luego probando ssh -T git@github.com ( como lo recomienda github) Esto pedirá aceptar el host y agregar una input al file ~ root / .ssh / known_hosts. Copie los contenidos de este file al lugar donde está trabajando en el proyecto.

Estamos creando todos los scripts de configuration en la carpeta .ebextensions / para configurar el server Linux para la implementación. Esta carpeta se elimina (por lo que puedo decir) del server después de la etapa de implementación previa. Estamos utilizando la solución Amazon AMI de PHP de 5.5 bits. Mueva las keys id_rsa e id_rsa.pub en la nueva carpeta .ebextensions. También agregue un file llamado known_hosts a la carpeta con el contenido de known_hosts que proporcionamos anteriormente. Ahora que tenemos los 3 files que necesitamos, necesitamos crear un file de instrucción de implementación final : 01-github-deploy-keys.config (nombre el file como quieras)

 container_commands: 11-move-priv-key: command: "mv ~root/.ssh/id_rsa ~root/.ssh/id_rsa.bak; cp .ebextensions/id_rsa ~root/.ssh/id_rsa; chmod 400 ~root/.ssh/id_rsa;" 12-move-pub-key: command: "mv ~root/.ssh/id_rsa.pub ~root/.ssh/id_rsa.pub.bak; cp .ebextensions/id_rsa.pub ~root/.ssh/id_rsa.pub; chmod 400 ~root/.ssh/id_rsa.pub;" 12-known-hosts: command: "mv ~root/.ssh/known_hosts ~root/.ssh/known_hosts.bak; cp .ebextensions/known_hosts ~root/.ssh/known_hosts; chmod 644 ~root/.ssh/known_hosts;" 20-install-composer: command: "./composer.phar install;" 

Recuerde que los files YAML usan 4 espacios, ¡no tabs! Consulte la documentation de AWS sobre cómo funcionan estos contenedores_commands: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html#customize-containers-format-commands Se ejecutarán después de que los files sean sacado del repository. Estos commands en la sección "commands_commands" tienen un directory de trabajo de su proyecto, por lo que se prefieren las routes locales.

Agregue que todos estos files deben agregarse y enviarse al repository. Ejecute su git aws.push para implementar.

Para probar la configuration correctamente, deberá quitar el server de la stack de soluciones EB y volver a agregarlo. Simplemente voy al panel de control de EC2 y encuentro el server administrado para este proyecto y lo termino. EB creará automáticamente uno nuevo para usted y lo adjuntará una vez que esté listo. Verifique sus loggings, específicamente la sección /var/log/cfn-init.log . Probablemente sea mejor desactivar el acceso SSH a los serveres a través del grupo de security en este momento. Creo que EB restringe los inicios de session a la raíz a través de SSH, pero solo para asegurarse de que desee deshabilitar el acceso SSH en set mediante firewall / grupos de security. No debería necesitar ingresar en cuadros individuales para la configuration, ya que deberían verse como volátiles.

Esto fue escrito como una session de preguntas y respuestas el 20-02-2020, por favor publique cualquier comentario o corrección.

Gracias, – Seth

TLDR: use ~ / .composer / auth.json, github-oauth en composer.json, o cree un script personalizado como el siguiente:


Este es mi file 02-github-deploy-keys.config. Está funcionando en este momento. La única solución era desactivar StrictHostKeyChecking. Pero puede activar StrictHostKeyChecking después de que se ejecute este script, si lo desea.

Agregué / vendé (sin ningún file) a Git para detener AWS del Composer automático antes de que las teclas estuvieran bien. Para hacerlo, creé un file .gitignore dentro / proveedor, con esto:

 * !.gitignore 

Estoy almacenando las keys (id_rsa) en un cubo S3, donde permití que personas "autorizadas" leyeran el file, pero puedes poner el file en tu repository github. Estas keys se generaron en un usuario de máquina ( https://developer.github.com/guides/managing-deploy-keys/#machine-users ).

 files: "/home/ec2-user/sshgit/composer.sh": mode: "00755" owner: ec2-user group: ec2-user encoding: plain content: | if [ ! -f /home/ec2-user/id_rsa ] ; then aws s3 cp s3://eb-files/id_rsa /home/ec2-user/id_rsa chmod 0400 /home/ec2-user/id_rsa fi eval `ssh-agent -s` ssh-add /home/ec2-user/id_rsa echo 'StrictHostKeyChecking no' >> /etc/ssh/ssh_config export COMPOSER_HOME=/root COMPOSER_HOME=/root /opt/elasticbeanstalk/support/composer.phar install --no-interaction container_commands: 01-run-composer: command: "/home/ec2-user/sshgit/composer.sh" 

Solo quería señalar que hay una manera más fácil (tal vez más arriesgada) de hacerlo agregando esto a composer.json:

 "config": { "github-oauth": { "github.com": "YOUR-OAUTH-KEY" } } 

Y hay un tercer path que no probé, pero puedes crear un ~ / .composer / auth.json, y el compositor probablemente entenderá tus tokens allí.

Luché con esto. Tengo repositorys en AWS CodeCommit y estaba buscando el path de menor resistencia para resolverlo. Intenté ~ / .composer / auth.json pero parece que el compositor se ejecuta antes de que pudiera get el file en su lugar, etc. etc.

Fui por un enfoque que incluye el directory de proveedores en mi repository (deshacerse de las carpetas .git dentro de modo que no los trate como submodules) y todo se publica en Elastic Beanstalk a través de un file comprimido que incluye esa carpeta.