Lorawan-stack: Proporcionar paquetes de sistema estándar como alternativa a Docker
Resumen:
Todas las principales distribuciones de Linux se basan en administradores de paquetes para instalar software de manera controlada y segura.
Esta propuesta es que los paquetes se creen en formatos RPM , deb y opkg como punto de partida, y que se agreguen formatos de paquetes adicionales en una fecha posterior.
¿Porqué necesitamos esto?
Muchas organizaciones empresariales evitan que git se conecte a cualquier servidor que no sea el suyo y es posible que tampoco permitan los comandos wget .
Con frecuencia, Docker tampoco está disponible dentro de estas organizaciones, sin embargo, el acceso a los repositorios de paquetes es una "cantidad conocida" y, por lo tanto, es más fácil de vender a los equipos de seguridad, especialmente porque los paquetes tienden a estar completamente firmados como parte del proceso de creación.
También hay situaciones para las que Docker simplemente no es una buena opción. Esto podría incluir cuando los integradores de sistemas/proveedores de servicios administrados deseen escalar utilizando algo AWS Auto Scaling Groups basado en instancias en lugar de contenedores, o para instalaciones completas en entornos seguros.
La instalación a través de herramientas de administración de configuración como Ansible, Chef o Puppet también es increíblemente difícil cuando no tiene paquetes disponibles.
Finalmente, la instalación desde un repositorio git en lugar de un paquete es difícil sin compiladores, lo que abre un riesgo de seguridad al instalar compiladores en sistemas de producción.
¿Qué ya hay?
Actualmente, tenemos la opción de elegir entre dos contenedores docker ( ttn-lw-stack y ttn-lw-cli ) o construir binarios del mismo nombre desde git.
La implementación se realiza a través docker pull o git clone , los cuales pueden no funcionar detrás de firewalls corporativos/educativos.
¿Lo que falta?
La capacidad de instalar a través yum , apt o opkg
¿Cómo propone implementar esto?
Esto debería ser relativamente fácil de implementar usando GO Releaser , sin embargo, GO no es un lenguaje con el que esté particularmente familiarizado (¡todavía!)
Ambiente:
Linux: basado en CentOS/RHEL, basado en Debian/Ubuntu, basado en OpenWRT
¿Qué puede hacer usted mismo y con qué necesita ayuda?
Necesitaría confirmación de que esta es la forma adecuada de empaquetar una aplicación go para su implementación, y luego algo de ayuda con la implementación de alguien que entienda GO!
proffalken
Todos 10 comentarios
Comenzaré agregando paquetes a APT, AUR y https://github.com/nixos/nixpkgs , ya que estoy familiarizado con el formato de estos. Otros se añadirán más tarde.
¡Las contribuciones son, por supuesto, siempre bienvenidas!
rvolosatovs
en 2 feb. 2019
@rvolosatovs , ¿usará go-releaser u otra forma de crear los paquetes?
¡Estaría feliz de trabajar en el lado RPM de las cosas siempre que sepa lo que está usando para crearlas! :)
proffalken
en 3 feb. 2019
También haremos que esto sea parte del CD.
También agregando brew a la lista de deseos.
johanstokking
en 3 feb. 2019
Solo añado mi apoyo a esto. Nunca antes había usado docker, y aunque aprecio que haya muchos lenguajes de programación, este fue un gran salto para alguien que nunca lo había hecho antes. Si bien instalar desde un repositorio es la forma en que a los desarrolladores les gusta hacer las cosas, no es muy amigable para los usuarios finales.
mrpackethead
en 11 feb. 2019
Gracias por todo su trabajo en esto, espero encontrar tiempo en los próximos días para agregar soporte RPM y probarlo.
proffalken
en 13 feb. 2019
@proffalken Construiremos el paquete RPM como parte de CI; podrá encontrarlo en nuestra página de lanzamientos una vez que hagamos un lanzamiento. (FYI, github también admite fuentes Atom para lanzamientos: https://github.com/thethingsnetwork/lorawan-stack/releases.atom)
Seguí tu sugerencia de usar goreleaser.
Con respecto al paquete RPM en sí, es (por ahora) solo https://github.com/TheThingsNetwork/lorawan-stack/blob/b1183962c502e6b53191086c23567c546c2b8ec5/.goreleaser.yml#L79 -L92
Sospecho que la ubicación de la interfaz, por ejemplo, no es estándar para los paquetes RPM y, de hecho, tampoco es predeterminada para la pila (esperamos que esté en /srv/ttn-lorawan/public ).
Por lo tanto, su opinión sobre cómo se debe hacer esto sería muy útil.
Tenga en cuenta que para brew , por ejemplo, ajustamos el binario de la pila para configurar la variable de entorno relacionada para que apunte a la interfaz:
https://github.com/TheThingsNetwork/lorawan-stack/blob/b1183962c502e6b53191086c23567c546c2b8ec5/.goreleaser.yml#L116 -L119
Estoy seguro de que la ubicación esperada de esto en el paquete RPM es diferente, pero con suerte podemos usar el mismo enfoque allí.
rvolosatovs
en 14 feb. 2019
@rvolosatovs tiene mucho sentido para mí.
La configuración de los env vars probablemente se realice mejor en un script de servicio systemd, intentaré armar uno tan pronto como pueda.
Meter cosas en /srv/ttn-lorawan/public también es perfectamente aceptable :)
proffalken
en 15 feb. 2019
@rvolosatovs , ¿puede actualizar las etiquetas y/o el comentario original para indicar que ya no necesitamos ayuda o ayuda con una distribución específica? Antes de que los miembros de la comunidad comiencen a implementar esto con entusiasmo mientras la mayor parte está en progreso.
johanstokking
en 18 feb. 2019
Bloqueado por falta de lanzamiento de v3.0.0 .
No tiene sentido publicar versiones preliminares en repositorios.
rvolosatovs
en 18 mar. 2019
Cerrado por liberación. Tenemos soporte para Snappy y Brew, así como archivos deb y rpm
johanstokking
en 9 abr. 2019
Temas relacionados
adriansmares
·
8Comentarios
kschiffer
·
4Comentarios
w4tsn
·
6Comentarios
kschiffer
·
6Comentarios
johanstokking
·
6Comentarios
Comentario más útil
También haremos que esto sea parte del CD.
También agregando
brewa la lista de deseos.