Lorawan-stack: Fornecer pacotes de sistema padrão como uma alternativa ao Docker
Resumo:
Todas as principais distribuições Linux contam com gerenciadores de pacotes para instalar software de maneira controlada e segura.
Esta proposta é que os pacotes sejam criados nos formatos RPM , deb e opkg como ponto de partida, com formatos de pacote adicionais sendo adicionados posteriormente.
Por que nós precisamos disso?
Muitas organizações empresariais impedem o git de se conectar a qualquer servidor que não seja o seu próprio e também podem não permitir comandos wget .
O Docker frequentemente também não está disponível nessas organizações, no entanto, o acesso aos repositórios de pacotes é uma "quantidade conhecida" e, portanto, mais fácil de vender para as equipes de segurança, especialmente porque os pacotes tendem a ser totalmente assinados como parte do processo de criação.
Há também situações para as quais o Docker simplesmente não é uma boa opção. Isso pode incluir quando integradores de sistemas/provedores de serviços gerenciados desejam dimensionar usando algo do AWS Auto Scaling Groups com base em instâncias em vez de contêineres ou para instalações bare-metal em ambientes seguros.
A instalação por meio de ferramentas de gerenciamento de configuração como Ansible, Chef ou Puppet também é incrivelmente difícil quando você não tem pacotes disponíveis.
Finalmente, instalar a partir de um repositório git ao invés de um pacote é difícil sem compiladores, o que abre um risco de segurança ao instalar compiladores em sistemas de produção.
O que já existe?
No momento, temos uma escolha entre dois contêineres docker ( ttn-lw-stack e ttn-lw-cli ) ou criar binários com o mesmo nome do git.
A implantação é feita por docker pull ou git clone , os quais podem não funcionar atrás de firewalls corporativos/educacionais.
O que está faltando?
A capacidade de instalar via yum , apt ou opkg
Como você se propõe a implementar isso?
Isso deve ser relativamente fácil de implementar usando GO Releaser , no entanto, GO não é uma linguagem com a qual estou particularmente familiarizado (ainda!)
Meio Ambiente:
Linux - baseado em CentOS/RHEL, baseado em Debian/Ubuntu, baseado em OpenWRT
O que você pode fazer sozinho e em que precisa de ajuda?
Eu precisaria de confirmação de que esta é a maneira apropriada de empacotar um aplicativo go para implantação e, em seguida, alguma ajuda com a implementação de alguém que entende de GO!
proffalken
Todos 10 comentários
Vou começar adicionando pacotes ao APT, AUR e https://github.com/nixos/nixpkgs , pois já estou familiarizado com o formato destes. Outros serão adicionados posteriormente.
Contribuições são, claro, sempre bem-vindas!
rvolosatovs
em 2 fev. 2019
@rvolosatovs você usará o go-releaser ou outra maneira de criar os pacotes?
Eu ficaria feliz em trabalhar no lado RPM das coisas, desde que eu saiba o que você está usando para criá-las! :)
proffalken
em 3 fev. 2019
Faremos esta parte do CD também.
Também adicionando brew à lista de desejos.
johanstokking
em 3 fev. 2019
Apenas adicionando meu apoio a isso. Eu nunca usei o docker antes e, embora eu aprecie que existam muitas linguagens de programação, esse foi um grande salto para alguém que nunca fez isso antes. Embora a instalação de um repositório seja como os desenvolvedores gostam de fazer as coisas, não é muito amigável para os usuários finais.
mrpackethead
em 11 fev. 2019
Obrigado por todo o seu trabalho nisso, espero encontrar tempo nos próximos dias para adicionar suporte a RPM e testá-lo.
proffalken
em 13 fev. 2019
@proffalken Construiremos o pacote RPM como parte do CI - você poderá encontrá-lo em nossa página de lançamentos assim que fizermos um lançamento. (FYI, o github também suporta feeds Atom para lançamentos: https://github.com/thethingsnetwork/lorawan-stack/releases.atom)
Eu segui sua sugestão de usar goreleaser.
Em relação ao pacote RPM em si - é (por enquanto) apenas https://github.com/TheThingsNetwork/lorawan-stack/blob/b1183962c502e6b53191086c23567c546c2b8ec5/.goreleaser.yml#L79 -L92
Suspeito que a localização do frontend, por exemplo, não seja padrão para pacotes RPM e, de fato, também não seja padrão para a pilha (esperamos que seja em /srv/ttn-lorawan/public ).
Portanto, sua opinião sobre como isso deve ser feito seria muito útil.
Observe que, para brew , por exemplo, agrupamos o binário da pilha para definir a variável de ambiente relacionada para apontar para o frontend:
https://github.com/TheThingsNetwork/lorawan-stack/blob/b1183962c502e6b53191086c23567c546c2b8ec5/.goreleaser.yml#L116 -L119
Tenho certeza de que a localização esperada disso no pacote RPM é diferente, mas esperamos poder usar a mesma abordagem lá.
rvolosatovs
em 14 fev. 2019
@rvolosatovs faz todo o sentido para mim.
A configuração do env vars provavelmente é melhor feita em um script de serviço do systemd, tentarei montar um assim que puder.
Colocar coisas em /srv/ttn-lorawan/public também é perfeitamente aceitável :)
proffalken
em 15 fev. 2019
@rvolosatovs você pode atualizar os rótulos e/ou comentário original para indicar que não precisamos mais de ajuda ou ajuda com uma distribuição específica? Antes que os membros da comunidade comecem a implementar isso enquanto a maior parte está em andamento.
johanstokking
em 18 fev. 2019
Bloqueado por falta de liberação de v3.0.0 .
Não faz sentido publicar versões de pré-lançamento em repositórios.
rvolosatovs
em 18 mar. 2019
Fechado por causa do lançamento. Temos suporte Snappy e Brew, bem como arquivos deb e rpm
johanstokking
em 9 abr. 2019
Questões relacionadas
johanstokking
·
8Comentários
htdvisser
·
4Comentários
thinkOfaNumber
·
4Comentários
johanstokking
·
6Comentários
adamsondelacruz
·
7Comentários
Comentários muito úteis
Faremos esta parte do CD também.
Também adicionando
brewà lista de desejos.