docker - leap - opensuse

Configuración de un entorno de desarrollo con ventana acoplable.

Question

Tengo algunos problemas para configurar la ventana acoplable para un entorno de desarrollo para mi equipo. Hasta aquí:

1. Usé una imagen base para comenzar un contenedor

   docker run -t -i ubuntu:latest "/bin/bash"

2. Instalé todas las herramientas de compilación y compilación en él.

3. Confié esa imagen y la envié a nuestro servidor local de docker.

   docker commit e239ab... 192.168.10.100:5000/team-dev:beta

Hasta ahora tan bueno. Ahora, actuando como un miembro del equipo:

1. Extraigo la imagen del entorno dev en mi computadora

   docker pull 192.168.10.100:5000/team-dev:beta

2. Comienzo un contenedor:

   docker run -t -i 5cca4... "/bin/bash"

En este punto, estoy pensando en mi contenedor como una especie de máquina remota en la que puedo SSH y trabajar.

Intento hacer un git clone desde dentro del contenedor, pero esto falla debido a un problema público. Copio los archivos id_rsa * en la ventana acoplable manualmente, y el clon funciona. Luego trato de editar algunos archivos de origen, pero mis configuraciones vim, configuraciones bash, todo se desecha porque este es un nuevo entorno de sistema operativo. Lo que funciona realmente bien es mi entorno completo de compilación con versiones dependientes.

Estas son las posibles soluciones en las que pienso ayudarme a solucionar esto.

1. Después de extraer la imagen básica, use un archivo docker para agregar todas las variables de entorno desde el host a la ventana acoplable.

   Contras: cada vez que mi entorno de host cambia bash / vim / git necesito actualizar el dockerfile

2. Utilice un volumen desde el host al contenedor. Git clonar y editar archivos en el host. Ejecute los scripts de compilación y las compilaciones desde dentro de la ventana acoplable.

   Contras: el contenido de un volumen de datos no se puede utilizar para actualizar la imagen si es necesario. No sé si esto es algo que debería preocuparme de todos modos.

¿O me estoy acercando a esto de manera incorrecta?

Answer 1

Así es como lo hago para mi aplicación nodejs.

Primero, tenga un Dockerfile como parte de la fuente que se ve así.

FROM node:0.10-onbuild
EXPOSE 8080
COPY . /src

Esto se utiliza para construir una imagen:

sudo docker build -t myapp .

Una vez creado, desarrollo mi código y uso lo siguiente para ver los cambios en mi contenedor:

sudo docker run --rm -it -p 8080:8080 --name="myapp" -v ''/path/to/app/src:/usr/src/app'' myapp:latest

Observe la -v aquí, estoy montando mi directorio local en el contenedor, por lo que no necesito reconstruir cada vez que hago un cambio de código.

El código es administrado por github, por lo que el flujo de desarrollo es el mismo. Hacer rama, trabajar localmente, una vez listo, volver a fusionar con el maestro.

Si mi aplicación se basa en otro servicio, por ejemplo, rabbitmq, agrego que este es un contenedor docker por separado y utilizo un archivo de configuración para mi aplicación.

Espero que esto sea de ayuda

Answer 2

Como joven usuario de la ventana acoplable, trataré de explicar cómo lo uso. Principalmente lo uso para dos cosas: aislar servicios y contener entornos complejos.

1. Servicios de aislamiento.

Resumen

Como la separación del principio de preocupación

Por qué ? Para reutilización y escalabilidad (depuración y mantenimiento también por cierto).
Por ejemplo, para tener un entorno de desarrollo para un sitio web de PHP Laravel, ejecutaría un par de contenedores:

• Mysql
• Apache-PHP
• Redis
• ..

Cada uno de estos contenedores (servicios) estaría vinculado entre sí para que puedan trabajar juntos. Por ejemplo:

Apache <== Mysql (3306 port).

El contenedor de Apache ahora puede abrir una conexión TCP con el contenedor Mysql a través del puerto 3306 expuesto .

Los proyectos similares se basarán en una sola imagen de Docker, pero se ejecutarán en diferentes contenedores. Pero todas las herramientas requeridas por una aplicación deben estar en contenedores para el trabajo en equipo.

Gestión de código fuente

Nunca coloco el código fuente directamente en un contenedor. Prefiero montarlo por volumen ( opción de docker run -v ) en el contenedor.

Cuando quiero ejecutar un comando que alterará mi código fuente, como compilar, ejecutar pruebas o actualizaciones de npm, lo hago desde el host o el contenedor, dependiendo de la cantidad de configuraciones que necesite esta herramienta para ejecutarse.
Cuanto más complicado o específico sea la aplicación, más consideraría hacerlo en el contenedor.

Contenedores de correr

Siguiendo el ejemplo anterior, ejecutaré los contenedores myapp y mysql .

$ cd myapp
$ docker run -d / # run as deamon (detached)
-p 82:80 / # bind container''s port 80 to host''s 82
-p 22001:22 / # bind container''s port 22 to host''s 22001
--expose 3306 # exposed to other container linked with it
--name mysql
author/mysqlimage
$ docker run -d / # run as deamon (detached)
-p 81:80 / # bind container''s port 80 to host''s 81
-p 22001:22 / # bind container''s port 22 to host''s 22001
-v $(pwd):/var/www # mount current host''s directory to container''s /var/www
--link mysql:db # give access to mysql container (ports) as db alias
--name myapp
author/apacheimage

myapp container podría hablar con mysql container. Para probarlo: $ telnet db 3306 funcionaría.

Ejecución de contenedores utilizando Fig.

Como dije, el cmd de Docker es una pesadilla para mí, así que encontré otra gran herramienta, Fig , que me hizo terminar con este archivo claro yaml, ubicado en la raíz de mi proyecto:

web:
image: lighta971/laravel-apache
links:
- db
ports:
- "81:80"
- "22001:22"
volumes:
- .:/app
db:
image: lighta971/phpmyadmin-apache
ports:
- "82:80"
- "22002:22"
expose:
- "3306"

Y luego $ cd myapp && fig up da el mismo resultado que los comandos a continuación :)

2. Contenerizar entornos complejos.

También estoy usando Docker para el desarrollo de Android. Una configuración básica de Android / Cordova es grande, como Gigs of downloads, que requiere tiempo para configurar el entorno.
Por eso puse todos los componentes en un único contenedor de "navaja suiza":

• SDK de Android
• Android NDK
• Hormiga apache
• Herramientas de android
• Java
• ...

Da como resultado una imagen con todo lo que necesito para configurar mi entorno Cordova:

$ docker run -i
--privileged # special permission for usb
-v /dev/bus/usb:/dev/bus/usb # mount usb volume
-v $(pwd):/app # mount current folder
-p 8001:8000
lighta971/cordova-env

Que alias en cvd :

$ alias cdv=''docker run -i --privileged -v /dev/bus/usb:/dev/bus/usb -v $(pwd):/app -p 8001:8000 lighta971/cordova-env''

Ahora puedo usar de forma transparente todos los programas dentro del contenedor como si estuviera instalado en mi sistema. Por ejemplo:

$ cdv adb devices # List usb devices
$ cdv cordova build android # Build an app
$ cdv cordova run android # Run an app on a device
$ cdv npm update # Update an app depedencies

Todos estos comandos funcionarán en el directorio actual debido a la opción de montaje de volumen $(pwd):/app .

Dockerfile

Todo lo dicho, hay otras cosas que saber, como:

• Entendiendo el proceso de construcción para hacer imágenes eficientes.
• lidiar con las necesidades de datos persistentes
• mantener los paquetes de imágenes actualizados
• etc.

Espero que te quede claro :)

Answer 3

Creé una imagen para usar Cordova en un contenedor docker con Java, JDK, administrador de SDK, gradle and maven, CLI angular, licencias aceptadas de Android, etc. https://hub.docker.com/r/walterwhites/docker-cordova/builds/

construir imagen

sudo docker build . -t walterwhites/cordova

Ejecutar el contenedor:

docker run -ti --rm --name=cordova -v /Users/username/workspace/gusto-coffee-mobile-app:/workspace walterwhites/cordova

opción -t es ejecutar el contenedor con terminal opción -i es ejecutar en modo interactivo opción -rm es detener el contenedor al salir de él opción -v es crear volumen para compartir entre su host (máquina local) y el contenedor

Nota para la aplicación de Android Tun en Córdoba:

añadir plataforma android:

cordova platform add android

construir:

cordova build android

Answer 4

Este es finalmente el flujo de trabajo con el que me conformé.

Puntos clave en la configuración de un entorno de desarrollo:

• Escribir código debe pasar fuera de la ventana acoplable.
• VCS debe estar fuera de la ventana acoplable
• Toda la compilación y ejecución debe estar dentro de la ventana acoplable.
• Los contenedores de Docker deben ser sin estado, de modo que la modificación y creación de un nuevo contenedor de ventana acoplable solo implica una recompilación, ejecución

Según lo sugerido por lighta hay dos opciones:

1. Cada servicio tiene una ventana acoplable.
2. Todos los servicios dentro de una ventana acoplable.

Preferí este último enfoque porque estoy trabajando en múltiples proyectos y siento que mxn dockers se siente peor que tener m dockers.

Configurando el medio ambiente:

• Comenzó con phusion_baseimage
• Mysql instalado, phpmyadmin, nodejs, grunt y sus amigos, apache, django
• Configure los servicios de inicio y el registro (una brisa con runit y svlogd que vienen junto con la imagen base) para iniciar apache, mysql, etc. en el inicio. Así que un inicio docker reiniciará estos servicios.
• Exponga los puertos necesarios (80 y, en general, 8000 para ejecutar un servidor de prueba)
• Ahora, defino mis puntos de montaje de la siguiente manera
  • ~/host/projectDocker/src > /root/project
  • ~/host/projectDocker/dbData/mysql_data > /var/lib/mysql
  • ~/host/projectDocker/apache_conf > /etc/apache/sites-enabled/

Esto ha funcionado muy bien hasta ahora. Cada vez que tenemos que instalar algunas bibliotecas o dependencias específicas (especialmente para Haskell), simplemente configuramos una nueva imagen y pedimos a todos los desarrolladores que extraigan la última imagen y reconstruyan sus contenedores. Voila!

Todo el granizo docker.

Answer 5

He intentado un montón de diferentes configuraciones de entorno de desarrollo para trabajar en la ventana acoplable.

El equipo con el que se quedó mi equipo fue un directorio predefinido donde se ubicaría el código, y luego se asignó al contenedor de la ventana acoplable como un directorio. Las variables de entorno necesarias se colocaron en el Dockerfile y se escribieron un montón de scripts de bash para iniciar los contenedores con las rutas necesarias asignadas. Almacenaríamos el Dockerfile en Git, y cada vez que se añadiera una nueva dependencia, tendríamos que actualizar el Dockerfile y, posiblemente, reconstruir la imagen (esto se debió principalmente a la forma en que manejamos la administración de dependencias, no fue ideal y no creo que sea necesario, pero dependerá de la pila de tecnología)

Nuestros scripts fueron por tecnología, debido a la cantidad de tecnologías diferentes que utilizamos. Todos nuestros contenedores se asignarían a una carpeta específica de tecnología que almacenaba todas las configuraciones. Por ejemplo, el directorio / opt / se convirtió en el directorio principal donde se ubicaría nuestro código. Cuando se ejecutó el comando de ejecución de la ventana acoplable, se asignaría en el directorio / opt / local al directorio / opt / en el contenedor de la ventana acoplable.

Esto generalmente funcionó.

Sin embargo, establecer un entorno de desarrollo local fue su propio desafío. Comencé con una máquina de Windows, que sacaría de git. Tenía eso asignado en una máquina virtual de Ubuntu que estaba ejecutando docker.

En la máquina virtual de ubuntu, tuve scripts de bash que iniciarían todos los contenedores docker necesarios.

./start-apache.sh
./start-mysql.sh
./start-mongodb.sh ... and so on

Esto finalmente dejó de funcionar cuando descubrí que debido a usar Windows como host, tuve problemas para crear enlaces simbólicos de los que dependía nuestro proyecto. Así que cambié a usar git en la máquina virtual de Ubuntu, y luego inicié todo en Ubuntu, usando los mismos scripts de bash.

La desventaja de esto era que básicamente estaba codificando en una máquina virtual, y no podía usar mi IDE de preferencia en Windows. No fue terrible, pero trabajar en una máquina virtual no es lo ideal, imo.

Esta configuración dejó mucho que desear. Tomó semanas lograrlo en un estado de mantenimiento para nuestro pequeño equipo de desarrollo. El proceso de flujo de trabajo podría haberse mejorado, pero no había tiempo ni se sabía cómo ...

Me interesaría conocer el flujo de trabajo de cualquier otra persona que hayan desarrollado para trabajar con la ventana acoplable.