Libelektra: crear una demostración en vivo de web-ui

El único plan realista para esta versión es crear y alojar una imagen de la ventana acoplable con una compilación manual de web-ui.

@omnidan ¿Puedes hacer eso?

apiario de la web elektrad + también sería parte de esto.

@omnidan, ¿tuviste tiempo para trabajar en esto o en el video?

Ya hice un video: https://drive.google.com/open?id=13dSC0ereCQGusrwlIodaDostW6eEes72

Intentaré crear una imagen de la ventana acoplable con la interfaz de usuario web instalada. ¿Existe ya una imagen de Docker que tenga libelektra instalado? ¿Dónde alojaríamos la imagen de la ventana acoplable?

¡Gracias, el video es genial! Si a veces haces otro video, tener un video sin estudiantes como ejemplo sería excelente: sonrisa: (por ejemplo, editar / etc / hosts)

¿Cuál es nuestra mejor opción para alojar el video, de modo que la reproducción del video funcione sin problemas en todos los navegadores? (En el enlace anterior, dos navegadores no pudieron reproducirlo directamente).

Tengo una instalación de nextcloud, podríamos probarla allí.

¿O es solo una cuestión del formato de video en el que se encuentra?

¿Existe ya una imagen de la ventana acoplable que tenga libelektra instalado?

Consulte scripts / docker para crear imágenes.

¿Dónde alojaríamos la imagen de la ventana acoplable?

Tenemos nuestro propio registro de Docker en https://hub.libelektra.org, pero hasta donde yo sé, aún no está disponible públicamente. @ingwinlu sabe más sobre eso.

@ markus2330 Lo subí a youtube (no listado), eso debería funcionar en todos los navegadores: https://youtu.be/lLg9sk6Hx-E

¿Por qué no cotizar?

@ markus2330 Puedo hacerlo público, pensé que solo querías usarlo para incrustarlo en el sitio web.

El público está bien para mí. ¿Podemos incrustarlo en las próximas notas de la versión o incluso publicarlo como comentario sobre las reacciones actuales de las notas de la versión?

¿Cuál es la licencia estándar de youtube?

No sé, lo cambié a CC BY

Creo que una imagen de la ventana acoplable con un Elektra completo (y más reciente) preinstalado podría ser muy útil para muchos casos de uso (de demostración) (no solo la interfaz de usuario web).

Así que estoy bastante interesado en tener una imagen de ventana acoplable: guiño:

@omnidan puede usar una imagen base extensible e instalar los paquetes desde nuestro repositorio. Eso debería ser bastante rápido y limpio.

Sin embargo, no tendrá acceso a ninguna función que aún no exista en los paquetes de Debian.

Gracias por el aporte.

Desafortunadamente, los paquetes de Debian aún no incluyen la interfaz de usuario web. Y sería algo bastante difícil de hacer (¿algún experto en empaquetado de nodejs por aquí?).

Y tener partes de Elektra instaladas como paquetes, y otras partes mediante "make install" no me suena realmente limpio (las versiones pueden no coincidir fácilmente).

@ingwinlu, ¿ sería posible que

Tener una imagen dockerfile + (¿tal vez en un registro Docker público si queremos mantener nuestro registro privado?) Con la última Elektra instalada sería realmente genial.

El repositorio de a7 no está configurado para acceso público. Y si el sistema de compilación no lo necesita, tiene más sentido incluirlo en el registro de Docker público.

Entonces, ¿el plan es que los desarrolladores reconstruyan sus propias imágenes de Docker? ¿O deberíamos poner todas las imágenes en un repositorio público?

¿Existe un daño potencial si permitimos el acceso de solo lectura?

Entonces, ¿el plan es que los desarrolladores reconstruyan sus propias imágenes de Docker?

Esa es una opción, o enviar manualmente la imagen desde uno de los esclavos de compilación al repositorio público. O reconfigurar el proxy inverso frente al registro para permitir que las solicitudes de obtención anónimas lleguen al punto final.

¿O deberíamos poner todas las imágenes en un repositorio público?

Eso ralentizará mucho el sistema de compilación en las actualizaciones de imágenes.

¿Existe un daño potencial si permitimos el acceso de solo lectura?

Ahora mismo no, ya que no debería haber credenciales sensibles en las imágenes. Sin embargo, la configuración incorrecta podría significar que cualquier clave / acceso necesario para el sistema de compilación podría filtrarse en las imágenes.

@ingwinlu Sí, un trabajo que se carga en un registro público parece una buena opción. ¿O podemos tener dos registros?

@omnidan ¿Está bien que escriba un Dockerfile para la interfaz de usuario web?

@ markus2330 Creé un Dockerfile y lo empujé al PR # 2032. También creé un grupo elektra en el registro de la ventana acoplable (puedo agregarte como propietario si me das tu ID de la ventana acoplable), publiqué un contenedor elektra/web:1.4.0 en el registro de la ventana acoplable y actualicé la documentación con información sobre cómo ejecutar elektra web a través de Docker y cómo crear nuevos contenedores / lanzamientos.

@ingwinlu ¿puedes alojar esta imagen de la

Seguro.

@omnidan, ¿puedes presionar hasta: lo último también? Luego, lo configuraré para verificar si hay nuevas versiones enviadas a: latest automáticamente y volver a implementar si hay una actualización.

@ markus2330 ¿ puede apuntar una entrada dns a a7. algo como webui o webdemo tal vez ?.

@ingwinlu ¡ Muchas gracias!
webui.libelektra.org webdemo.libelektra.org debería apuntar a a7 en breve.

@omnidan El webui podría ser más interesante si crea algunos puntos de montaje en las imágenes. kdb mount-info y kdb mount --with-recommends /etc/hosts system/hosts hosts serían un buen comienzo!

@ingwinlu ya puede usar :latest , usa :1.4 ahora mismo (publicará :1.5 a más tardar cuando el RP se fusione)

Preferiría que pudiéramos tener 1.5 inmediatamente, hay poco uso de probar 1.4 ahora. ¿Pensé que la fusión no es necesaria?

@omnidan , parece que no entiende cómo funciona la etiqueta latest : https://medium.com/@mccode/the -misundersknown-docker-tag-latest-af3babfd6375

https://hub.docker.com/r/elektra/web/tags/ no muestra latest . Debe presionarlo explícitamente.

¡Gracias por señalar esto!

¿Puede iniciar la imagen de la ventana acoplable 1.5.0-beta en a7 para que tengamos algo que probar mañana en la reunión?

http://a7.complang.tuwien.ac.at : 33334 /

No pude invertir el proxy porque los puertos están codificados (y eso no funcionará con la configuración actual). También tenga en cuenta que elektra se está ejecutando como usuario root en el contenedor, lo que me hace sentir muy incómodo.

http://webui.libelektra.org : 33334 / ¡también funciona! Gracias: 100: veces.

También tenga en cuenta que elektra se está ejecutando como usuario root en el contenedor, lo que me hace sentir muy incómodo.

No se preocupe, no es root (sino 999) y ni siquiera es posible escribir en las claves del sistema: could not create configuration directory: Could not create directory "/etc/kdb", because: "Permission denied" uid: 999, euid: 999, gid: 999, egid: 999

Sí, pero no es un proxy, por lo que tampoco https. Está simplemente amañado para correr
ahora, pero no lo mantendría así a largo plazo.

markus2330 [email protected] schrieb am Fr., 1. Juni 2018, 10:38:

http://webui.libelektra.org : 33334 / ¡también funciona! Gracias 💯 veces.

También tenga en cuenta que elektra se ejecuta como usuario root en el contenedor que
me incomoda como el infierno.

No te preocupes, no es root (sino 999) y ni siquiera es posible
escribir en las claves del sistema: no se pudo crear el directorio de configuración: no se pudo
cree el directorio "/ etc / kdb", porque: "Permiso denegado" uid: 999, euid:
999, gid: 999, egid: 999

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ElektraInitiative/libelektra/issues/1901#issuecomment-393810941 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AEOv-lxXTk85wCl8ipo7okci3PKztfWhks5t4P1jgaJpZM4TRVIf
.

los puertos están codificados

El problema aquí es que ejecutamos elektrad y webd en un contenedor, lo que va en contra de los principios de Docker. Así que solo puedo hacer que uno de los dos puertos sea ajustable (lo que debería ser suficiente, siempre y cuando estemos bien con elektrad encendido: 33333)

También tenga en cuenta que elektra se está ejecutando como usuario root en el contenedor, lo que me hace sentir muy incómodo.

Me aseguré específicamente de crear y usar un usuario elektra en el Dockerfile, a menos que haya hecho algo mal.

Sí, lo siento por el mensaje apresurado (estoy completamente lleno de citas este fin de semana + mis últimas compilaciones maestras rotas).

Hay dos grandes problemas con el Dockerfile actual:

múltiples procesos :
aunque ya dijiste que está en contra de los "principios" hacerlo, se dice principalmente que es un principio porque si rompes la regla necesitas entender qué está sucediendo y por qué es un problema.
Crea un script de shell que inicia dos procesos. Este script de shell se ejecuta a través de PID 1. Esto es algo especial para Docker, ya que se usa como el sistema 'init' que conoce de los sistemas operativos tradicionales. Por lo tanto, este es el pid que necesita controlar / reiniciar / registrar todos los demás procesos que inicie.
Para contenedores de un solo proceso, esto es trivial ya que el proceso iniciado generalmente lo hace de todos modos por sí mismo. Para procesos múltiples, necesita una envoltura.
Hay documentación disponible https://docs.docker.com/config/containers/multi-service_container/
http://supervisord.org/ también es muy popular para resolver el problema.
O echa un vistazo a cómo funcionan los contenedores de la página de inicio actual que escribí el mes pasado para dividirlos en contenedores de un solo servicio.

puertos :
Intenté usar el proxy 33334 y tuvo problemas para conectarse al backend incluso cuando estaba expuesto.
Si bien no solucioné completamente el problema, sospecho que se debe a que la ubicación del backend está codificada en algo como localhost: 33334 que se rompe en ese caso ya que el contenedor no lo expone en localhost sino en su nombre de host generado aleatoriamente.
Una solución a largo plazo probablemente sería establecer el backend en el nombre de host del contenedor en su script de inicio o dividir nuevamente los contenedores y simplemente apuntar el frontend al backend.
Nuevamente, puede encontrar inspiración para el segundo caso en nuestros contenedores de página de inicio existentes (que no son perfectos pero resuelven ese problema).

Tengo más tiempo la semana que viene y puedo ayudarte a reescribir los archivos si te atascas.

Para contenedores de un solo proceso, esto es trivial ya que el proceso iniciado generalmente lo hace de todos modos por sí mismo.

@ingwinlu desafortunadamente, no parece que Node.js haga esto: / Sin embargo, creo que esto podría resolverse pasando la bandera --init al ejecutar contenedores. (https://www.elastic.io/nodejs-as-pid-1-under-docker-images/)

Sospecho que se debe a que la ubicación del backend está codificada en algo como localhost: 33334, lo que se rompe en ese caso, ya que el contenedor no lo expone realmente en localhost sino en su nombre de host generado aleatoriamente.

En realidad, la ubicación no está codificada. El cliente siempre se sirve en el mismo host / puerto que el backend (webd), y simplemente accede a /api/ en el mismo host.

Creo que la mejor manera de hacerlo es separar las imágenes elektrad y webd, luego configurar la var PORT env también funcionará correctamente.

node.js en pid 1

No confiaría en --init . Pero un proceso de envoltura como el que introdujeron en el artículo suena bien.

En realidad, la ubicación no está codificada. El cliente siempre se sirve en el mismo host / puerto que el backend (webd), y simplemente accede a / api / en el mismo host.

Una vez más no tuve tiempo de depurarlo. Configuré 33334 para ser proxy inverso en una de las direcciones que apuntamos a a7. Resultó en fallas al cargar el sitio web porque no podía acceder a una dirección que necesitaba cargar. Este también fue el caso de exponer 33333: 33333 directamente con 33334 como proxy inverso en 443 (https).

Ok, entonces el nuevo plan es:

1. @ingwinlu crea un archivo @omnidan, ¿ puede darnos acceso al registro de docker.com para elektra? ¿Necesita algo más que los nombres de cuenta? ?)
2. Sobre la base de esa imagen, @omnidan (con reseñas de @ingwinlu) crea tres archivos / imágenes de Docker más que se crean con el mismo trabajo de compilación (o extensiones del mismo):
   
   
   
   1. imagen ampliada con Elektra completo (para hacer que la interfaz de usuario web sea más interesante),
   
   
   2. imagen ampliada con elektrad (para demostración en vivo, parte 1)
   
   
   3. imagen extendida con cliente / web (para demostración en vivo, parte 2)
   
   

Como producto final, tenemos un trabajo de compilación que genera cuatro imágenes de Elektra para cada confirmación en el maestro:

1. una mínima para minimalistas (o con poco ancho de banda)
2. una imagen de prueba completa de Elektra (para personas que prueban Elektra)
3. una imagen que inicia elektrad (para nuestra demostración en vivo y las personas que prueban la interfaz de usuario web)
4. una imagen que inicia el cliente / web (para nuestra demostración en vivo y las personas que prueban la interfaz de usuario web)

¿Está bien para ustedes dos?

¿Necesita algo más que los nombres de cuenta?

Necesito sus nombres de usuario de Docker Hub, eso es todo.

Basado en esa imagen

¿Está listo todavía?

Gracias, mi nombre de usuario de Docker Hub (ID de Docker) es markus2330

https://hub.docker.com/u/elektra/ dice que elektra / web ya tenía 10k + pulls. ¿Es tan popular o nuestra configuración está haciendo algo mal?

@ingwinlu ¿Podemos reactivar el servidor de compilación para que "webui.libelektra.org" se actualice a 1.5? ¿O puede implementar ese trabajo?

el buildserver no tiene absolutamente nada que ver con webui.libelektra.org.

se configuró para extraer siempre la última etiqueta 1.5.0-beta. Lo modifiqué para que use: último ahora.

Ver arriba, propuse un plan para que las imágenes de la ventana acoplable se creen y publiquen, por lo que deberían estar relacionadas.

¿Quiere decir que el servidor de compilación no implementa webui? ¿Hay alguna diferencia entre la implementación de webui y la página de inicio? Y si es así, ¿por qué?

se configuró para extraer siempre la última etiqueta 1.5.0-beta. Lo modifiqué para que use: último ahora.

¡Gracias! ¿Se actualiza automáticamente? ¿Cuándo?

Ver arriba, propuse un plan para que las imágenes de la ventana acoplable se creen y publiquen, por lo que deberían estar relacionadas.

¿Quiere decir que el servidor de compilación no implementa webui? ¿Hay alguna diferencia entre la implementación de webui y la página de inicio?

Porque nadie lo ha hecho. Solo lo configuré rápidamente como se ve en los comentarios anteriores.

Y si es así, ¿por qué?

Porque a nadie le interesaba hacerlo, al menos yo no lo sé. También hay varias preguntas para responder primero:

• ¿De dónde deberíamos obtener las etiquetas para las imágenes?
• ¿Cómo configurar la subida al registro público?
• ¿Cómo configurar los derechos de acceso al registro público?
• ¿Cuándo se deben ejecutar las compilaciones?
• ...

Actualmente no tengo ningún interés en implementarlo ya que tengo asuntos más urgentes que atender.

Y si es así, ¿por qué?

La pregunta se refería a por qué existen diferencias entre webui y la implementación de la página de inicio. Podríamos enviar las imágenes de la interfaz de usuario web a nuestro registro privado, ¿cuál debería resolver las preguntas?

Enviar a docker.com se puede hacer manualmente por ahora (para las versiones). Pero automatizar esto sería muy apreciado.

@omnidan ¿Ya nos ha agregado a hub.docker.com? Nombre de usuario: markus2330

las nuevas imágenes de la ventana acoplable divididas (las que solo ejecutan un proceso) podrían compilarse, enviarse e implementarse de manera idéntica a la página de inicio. probablemente.

@ markus2330 Te agregué como propietario, deberías poder agregar nuevos miembros en https://hub.docker.com/u/elektra/dashboard/teams/?team=owners ahora

Yo diría que mantenemos webui.libelektra.org para tener la imagen pública de Docker.

Y webdemo.libelektra.org se reconstruye en cada confirmación en master.

@ingwinlu ¿Qué opinas?

Lo cambié a webdemo.libelektra.org en el # 2110 PR

¿Creo que podemos cerrar esto ahora?

@omnidan ¿Puede actualizar también la página principal? El "Próximo:" ahora es verdadero: sonrisa: (la captura de pantalla también se puede mejorar).

¡Gran trabajo de ustedes dos, gracias!

@ markus2330 sí, podemos cerrar esto. ¡Mañana te enviaré un PR rápido para la página de inicio!

Gracias a ambos también, especialmente a @ingwinlu por explicarme docker y jenkins y corregir mis dockerfiles (¡aprendí mucho sobre docker de ustedes!)