Solución:
Después de un buen día de esfuerzo, finalmente habilité el uso de los repositorios privados de GitHub de mi organización con Elastic Beanstalk simplemente usando un .config
expediente. Estoy usando Python y pip
, pero también debería funcionar para otros instaladores de paquetes en EB.
rhetonik’s ssh-agent
+ssh-add
El enfoque no me funcionó en absoluto, así que elegí configurar un archivo de configuración ssh en su lugar.
Aquí está mi .ebextensions/3-pip-install-from-github.config
expediente:
files:
"/root/.ssh/config":
owner: root
group: root
mode: "000600"
content: |
Host github.com
User git
Hostname github.com
IdentityFile /root/.ssh/github
commands:
01-command:
command: sudo ssh-keyscan -H github.com >> /root/.ssh/known_hosts
02-command:
command: sudo chmod 644 /root/.ssh/known_hosts
03-command:
command: sudo aws s3 cp s3://bucket-with-your-github-ssh-key/github /root/.ssh
04-command:
command: sudo chmod 600 /root/.ssh/github
Instrucciones aproximadas:
-
Configure un depósito de S3 al que pueda acceder su instancia de EB. Dentro de ese depósito, almacene la clave SSH que permite el acceso al repositorio de GitHub al que desea acceder a través de
pip
,npm
,bundle
, etc. Utilicesudo aws s3 cp
para copiar esa clave en su instancia de EB durante la implementación.sudo
es necesario porque los scripts EB utilizanroot
y noec2-user
. -
Este archivo de configuración de ebextensions también crea 2 archivos en su instancia de EB.
/root/.ssh/config
dicessh
(invocado porpip
ygit
) para usar la clave que copió de S3. Almacenar la salida dessh-keyscan -H github.com
dentro/root/.ssh/known_hosts
comprobará previamente quessh
en su instancia de EB se está comunicando con GitHub para evitar ataques MITM. Esto es mejor que deshabilitarStrictHostKeyChecking
en/root/.ssh/config
.
Aquí está mi requirements.txt
archivo para pip
:
Beaker==1.7.0
Flask==0.10.1
Jinja2==2.7.3
MarkupSafe==0.23
# [...]
git+ssh://[email protected]/myorganization/[email protected]
Mientras corre eb-deploy
, usted puede tail -f /var/log/eb-activity.log
para asegurarse de que todo funcione sin problemas.
Así es como finalmente lo hice. Se trata de configurar una clave SSH para el usuario responsable de bundle install
fase.
- Inicie un entorno para una aplicación en AWS Elastic Beanstalk
- Opcional – Inicie sesión en la consola de Amazon EC2 y cambie el tipo de instancia al valor deseado
- Actualice el nombre del par de claves SSH para habilitar el inicio de sesión SSH remoto. (Estoy seguro de que debe haber una forma de especificar el tipo de instancia y el nombre del par de claves SSH al iniciar un entorno)
- Busque la instancia recién lanzada en la consola EC2 o a través de CLI, tenga en cuenta la Nombre de dominio completo (FQDN) para este caso. Las instancias de EB son como cualquier otra instancia que crearía con Amazon EC2. Inicie sesión a través de SSH en esta instancia.
- Ejecute los siguientes comandos para crear una clave SSH para
root
usuario
$ sudo su – raíz
$ ssh-keygen -t rsa -C “[email protected]”
-
Editar
.bash_profile
para comenzar explícitamentessh-agent
y agregue la clave SSH recién generada. Agregue las siguientes líneas (esto puede parecer innecesario, lo hice solo para estar seguro)eval `ssh-agent
eval
ssh-add ~/.ssh/id_rsa
-
Tenga en cuenta la clave pública SSH, por ejemplo:
~/.ssh/id_rsa.pub
y agréguelo al conjunto de claves SSH para la cuenta de Github que tiene acceso a repositorios privados -
En este punto, su instancia tiene acceso a sus repositorios privados de Github. Puede probar esto emitiendo un
git clone
en esos repositorios iniciando sesión comoroot
usuario. -
Cree una AMI a partir de esta instancia mediante métodos estándar
-
Vuelva a su panel de AWS Elastic Beanstalk y busque
Edit Configuration
opción en el entorno de su aplicación. En elServer
pestaña, busque una opción que le permita especificar unCustom AMI
. Actualice este campo con el ID de AMI recién creado, por ejemplo:ami-4324fd4
. -
Guarde la configuración presionando
Apply Changes
. AWS Elastic Beanstalk comenzaría a implementar nuevas instancias en su entorno y terminaría con las antiguas. Esto es para garantizar que todas sus instancias escaladas automáticamente tengan la clave SSH en la lista blanca requerida para el acceso privado a Github.
Una vez realizados los pasos anteriores, puede continuar e implementar su aplicación Rails con git aws.push
Espero que esto ayude a otros que están atascados. Sin embargo, me alegraría ver una solución más elegante que esta.
Si tiene prisa y el repositorio de su aplicación también es privado, puede crear una cuenta de usuario de Github adicional y asignarle privilegios de solo lectura al repositorio que contiene la gema.
Luego, proporcione al paquete la URL https con las credenciales de la nueva cuenta:
gem 'somegemname', git: "https://username:[email protected]/example/privaterepository"