Libelektra: criar demonstração ao vivo de web-ui

O único plano realista para esta versão é construir e hospedar uma imagem docker com uma construção manual de web-ui.

@omnidan Você pode fazer isso?

apiário da web elektrad + também faria parte disso.

@omnidan você teve tempo para trabalhar neste ou no vídeo?

Já fiz um vídeo: https://drive.google.com/open?id=13dSC0ereCQGusrwlIodaDostW6eEes72

Vou tentar construir uma imagem docker com o web-ui instalado. Já existe uma imagem do docker com o libelektra instalado? Onde hospedaríamos a imagem docker?

Obrigado, o vídeo é ótimo! Se acontecer de você fazer outro vídeo às vezes, ter um vídeo sem alunos como exemplo seria excelente: sorria: (por exemplo, editando / etc / hosts)

Qual é a nossa melhor opção para hospedar o vídeo, para que a reprodução do vídeo funcione perfeitamente em todos os navegadores? (No link acima, dois navegadores não conseguiram reproduzi-lo diretamente.)

Eu tenho uma instalação do nextcloud, podemos tentar lá.

Ou é apenas uma questão de formato de vídeo?

Já existe uma imagem do docker com o libelektra instalado

Veja scripts / docker para construir imagens.

Onde hospedaríamos a imagem docker?

Temos nosso próprio registro docker em https://hub.libelektra.org, mas até onde eu sei, ainda não está disponível publicamente. @ingwinlu sabe mais sobre isso.

@ markus2330 Fiz upload para o youtube (não listado), que deve funcionar em todos os navegadores: https://youtu.be/lLg9sk6Hx-E

Por que não listado?

@ markus2330 Posso torná-lo público, apenas pensei que você só queria usá-lo para incorporar no site.

Público está bom para mim. Podemos incorporá-lo nas próximas notas de lançamento ou até mesmo postá-lo como comentário às reações atuais das notas de lançamento?

Qual é a licença padrão do youtube?

Não sei, mudei para CC BY

Acho que uma imagem do docker com um Elektra completo (e mais recente) pré-instalado pode ser muito útil para muitos casos de uso (demo) (não apenas a IU da Web).

Portanto, estou muito interessado em ter uma imagem do docker: wink:

@omnidan você pode usar uma imagem de base esticada e instalar os pacotes de nosso repo. Isso deve ser bastante rápido e limpo.

Porém, você não terá acesso a nenhum recurso que ainda não exista nos pacotes debian.

Obrigado pela contribuição.

Infelizmente, os pacotes Debian ainda não incluem a IU da Web. E seria uma coisa bastante difícil de fazer (algum especialista em empacotamento nodejs por aqui?).

E ter partes do Elektra instaladas como pacotes e outras partes por "make install" realmente não parece limpo para mim (as versões podem facilmente não combinar).

@ingwinlu seria possível hospedar uma imagem Docker em a7 que foi criada por @omnidan? Ou você mesmo pensa em escrever um Dockerfile para a IU da Web?

Ter uma imagem dockerfile + (talvez em um registro Docker público se quisermos manter nosso registro privado?) Com o Elektra mais recente instalado seria realmente ótimo.

O repositório a7 não está configurado para acesso público. E se não for necessário para o sistema de compilação, faz mais sentido colocá-lo no registro docker público.

Então, o plano é que os desenvolvedores reconstruam suas próprias imagens do docker? Ou devemos colocar todas as imagens em um repositório público?

Existe um perigo potencial se permitirmos o acesso somente leitura?

Então, o plano é que os desenvolvedores reconstruam suas próprias imagens do docker?

Essa é uma opção, ou enviar manualmente a imagem de um dos escravos de construção para o repositório público. Ou reconfigurar o proxy reverso na frente do registro para permitir que solicitações anônimas cheguem ao terminal.

Ou devemos colocar todas as imagens em um repositório público?

Isso tornará o sistema de compilação muito lento nas atualizações de imagem.

Existe um perigo potencial se permitirmos o acesso somente leitura?

No momento, não, pois não deve haver credenciais confidenciais nas imagens. No entanto, a falta de configuração pode significar que qualquer chave / acesso necessário para o sistema de compilação pode vazar para as imagens.

@ingwinlu Sim, um trabalho que carrega em um registro público parece uma boa opção. Ou podemos ter dois registros?

@omnidan Você pode escrever um Dockerfile para a IU da Web?

@ markus2330 Criei um Dockerfile e enviei para o PR # 2032. Eu também criei um grupo elektra no registro do docker (posso adicioná-lo como proprietário se você me der sua id do docker), publiquei um contêiner elektra/web:1.4.0 no registro do docker e atualizei a documentação com informações sobre como executar elektra web via docker e como criar novos contêineres / lançamentos.

@ingwinlu você pode hospedar esta imagem docker na v7? (Para que ele comece automaticamente quando o servidor for iniciado?)

Certo.

@omnidan você pode enviar para: mais recente também? Em seguida, irei configurá-lo para verificar se há novas versões enviadas para: mais recente automaticamente e reimplantar se houver uma atualização.

@ markus2330 você pode apontar uma entrada dns para a7. algo como webui ou webdemo talvez ?.

@ingwinlu Muito obrigado!
webui.libelektra.org webdemo.libelektra.org deve apontar para a7 em breve.

@omnidan O webui pode ser mais interessante se você criar alguns pontos de montagem nas imagens. kdb mount-info e kdb mount --with-recommends /etc/hosts system/hosts hosts seria um bom começo!

@ingwinlu você já pode usar :latest , ele usa :1.4 agora (publicará :1.5 no mais tardar quando o PR for mesclado)

Eu preferiria que pudéssemos ter 1.5 imediatamente, há pouco uso de testar 1.4 agora. Eu pensei que a fusão não é necessária?

@omnidan, você parece estar entendendo mal como a tag latest funciona: https://medium.com/@mccode/the -misundersgether-docker-tag-latest-af3babfd6375

https://hub.docker.com/r/elektra/web/tags/ não mostra latest . Você precisa empurrá-lo explicitamente.

Obrigado por apontar isto!

Você pode iniciar a imagem docker 1.5.0-beta em a7 para que tenhamos algo para experimentar amanhã na reunião?

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

Não consegui reverter o proxy porque as portas estão codificadas (e isso não funcionará com a configuração atual). Observe também que elektra está executando como usuário root no contêiner, o que me deixa muito desconfortável.

http://webui.libelektra.org : 33334 / também funciona! Obrigado: 100: vezes.

Observe também que elektra está executando como usuário root no contêiner, o que me deixa muito desconfortável.

Não se preocupe, não é root (mas 999) e nem mesmo é possível escrever nas chaves do sistema: could not create configuration directory: Could not create directory "/etc/kdb", because: "Permission denied" uid: 999, euid: 999, gid: 999, egid: 999

Sim, mas não é proxy, então também não há https. É apenas preparado para correr por
agora, mas não iria mantê-lo assim no longo prazo.

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

http://webui.libelektra.org : 33334 / também funciona! Obrigado 💯 vezes.

Observe também que elektra está sendo executado como usuário root no contêiner que
me deixa desconfortável como o inferno.

Não se preocupe, não é root (mas 999) e nem é possível
escrever nas chaves do sistema: não foi possível criar o diretório de configuração: não foi possível
crie o diretório "/ etc / kdb", porque: "Permissão negada" uid: 999, euid:
999, gid: 999, egid: 999

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ElektraInitiative/libelektra/issues/1901#issuecomment-393810941 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEOv-lxXTk85wCl8ipo7okci3PKztfWhks5t4P1jgaJpZM4TRVIf
.

as portas são codificadas

O problema aqui é que executamos elektrad e webd em um contêiner, o que vai contra os princípios do docker. Portanto, só posso fazer com que uma das duas portas seja ajustável (o que deve ser suficiente, contanto que estejamos bem com o elektrad ligado: 33333)

Observe também que elektra está executando como usuário root no contêiner, o que me deixa muito desconfortável.

Eu especificamente me certifiquei de criar e usar um usuário elektra no Dockerfile, a menos que eu tenha feito algo errado.

Sim, desculpe pela mensagem apressada (estou completamente cheio de compromissos neste fim de semana + meu último pr quebrou master builds).

Existem dois grandes problemas com o Dockerfile atual:

processos múltiplos :
embora você já tenha dito que isso é contra 'princípios', é principalmente considerado um princípio porque, se você quebrar a regra, precisa entender o que está acontecendo e por que é um problema.
Você cria um script de shell que inicia dois processos. Este script de shell é executado através do PID 1. Isso é especial para o Docker, pois é usado como o sistema 'init' que você conhece dos sistemas operacionais tradicionais. Portanto, este é o pid que precisa controlar / reiniciar / registrar todos os outros processos que você iniciar.
Para contêineres de processo único, isso é trivial, pois o processo iniciado geralmente faz isso por si mesmo. Para processos múltiplos, você precisa de um invólucro.
Existe alguma documentação disponível https://docs.docker.com/config/containers/multi-service_container/
http://supervisord.org/ é muito popular para resolver o problema também.
Ou você dá uma olhada em como os contêineres de homepage atuais funcionam que escrevi no mês passado para dividi-los em contêineres de serviço únicos.

portas :
Tentei fazer proxy 33334 e ele teve problemas para se conectar ao back-end, mesmo quando foi exposto.
Embora eu não tenha solucionado totalmente o problema, suspeito que seja porque o local do back-end está codificado para algo como localhost: 33334, que é interrompido nesse caso, pois o contêiner não o está expondo no localhost, mas em seu nome de host gerado aleatoriamente.
Uma solução de longo prazo provavelmente seria definir o back-end para o nome do host dos contêineres em seu script de inicialização ou novamente dividir os contêineres e apenas apontar o front-end para o back-end.
Novamente, você pode encontrar inspiração para o segundo caso em nossos contêineres de homepage existentes (que não são perfeitos, mas resolvem esse problema).

Eu tenho mais tempo na próxima semana e posso ajudá-lo a reescrever os arquivos se você ficar preso.

Para contêineres de processo único, isso é trivial, pois o processo iniciado geralmente faz isso por si mesmo.

@ingwinlu , infelizmente, não parece que o Node.js faça isso: / Acho que isso poderia ser resolvido passando o sinalizador --init ao executar contêineres. (https://www.elastic.io/nodejs-as-pid-1-under-docker-images/)

Suspeito que seja porque o local do back-end está codificado para algo como localhost: 33334, que falha nesse caso, pois o contêiner não está realmente o expondo no localhost, mas em seu nome de host gerado aleatoriamente.

O local, na verdade, não está codificado. O cliente é sempre servido no mesmo host / porta que o backend (webd) e simplesmente acessa /api/ no mesmo host.

Acho que a melhor maneira de fazer isso é separar as imagens elektrad e webd e, em seguida, definir PORT env var também funcionará corretamente.

node.js em pid 1

Eu não confiaria em --init . Mas um processo de empacotamento como o apresentado no artigo parece bom.

O local, na verdade, não está codificado. O cliente é sempre servido no mesmo host / porta que o back-end (webd) e simplesmente acessa / api / no mesmo host.

Mais uma vez, não tive tempo de depurar. Eu configurei 33334 para ser proxy reverso em um dos endereços que apontamos para a7. Isso resultou em falhas ao carregar o site porque não foi possível acessar um endereço que precisava carregar. Este também foi o caso de expor 33333: 33333 diretamente com 33334 sendo proxy reverso em 443 (https).

Ok, então o novo plano é:

1. @ingwinlu cria um arquivo docker Elektra mínimo e um trabalho de compilação que cria automaticamente a imagem e a publica em docker.com ( @omnidan, você pode nos dar acesso ao registro docker.com para elektra? Você precisa de outra coisa além dos nomes de conta ?)
2. Com base nessa imagem, @omnidan (com análises de @ingwinlu) cria mais três arquivos / imagens Docker que são construídos pelo mesmo trabalho de construção (ou extensões dele):
   
   
   
   1. imagem estendida com Elektra completo (para tornar a IU da Web mais interessante),
   
   
   2. imagem estendida com elektrad (para demonstração ao vivo, parte 1)
   
   
   3. imagem estendida com cliente / web (para demonstração ao vivo, parte 2)
   
   

Como produto final, temos um trabalho de construção que cria quatro imagens Elektra para cada commit no master:

1. um mínimo para minimalistas (ou com pouca largura de banda)
2. uma imagem de teste Elektra completa (para pessoas que estão experimentando Elektra)
3. uma imagem que inicia elektrad (para nossa demonstração ao vivo e pessoas experimentando a IU da Web)
4. uma imagem que inicia o cliente / web (para nossa demonstração ao vivo e pessoas experimentando a IU da Web)

Tudo bem para vocês dois?

Você precisa de algo diferente dos nomes de conta?

Preciso dos seus nomes de usuário do Docker Hub, só isso.

Com base nessa imagem

Já está pronto?

Obrigado, meu nome de usuário do Docker Hub (Docker ID) é markus2330

https://hub.docker.com/u/elektra/ diz que elektra / web já teve mais de 10k pulls. É tão popular ou nossa configuração está fazendo algo errado?

@ingwinlu Podemos

o buildserver não tem absolutamente nada a ver com webui.libelektra.org.

ele foi configurado para sempre puxar a última tag 1.5.0-beta. Eu modifiquei para que use: mais recente agora.

Veja acima, eu propus um plano para que as imagens docker sejam construídas e publicadas, então elas devem ser relacionadas.

Quer dizer que o servidor de compilação não implanta webui? Existe alguma diferença na implantação do webui e da página inicial? E se sim, por quê?

ele foi configurado para sempre puxar a última tag 1.5.0-beta. Eu modifiquei para que use: mais recente agora.

Obrigado! É atualizado automaticamente? Quando?

Veja acima, eu propus um plano para que as imagens docker sejam construídas e publicadas, então elas devem ser relacionadas.

Quer dizer que o servidor de compilação não implanta webui? Existe alguma diferença na implantação do webui e da página inicial?

Porque ninguém fez isso. Eu apenas configurei rapidamente como visto nos comentários acima.

E se sim, por quê?

Porque ninguém se interessou em fazê-lo, pelo menos não estou ciente disso. Existem também várias perguntas para responder primeiro:

• De onde devemos obter as tags das imagens?
• Como configurar o upload para o registro público?
• Como configurar direitos de acesso ao registro público?
• Quando as compilações devem ser executadas?
• ...

No momento, não tenho interesse em implementá-lo, pois tenho assuntos mais urgentes para tratar.

E se sim, por quê?

A questão referia-se a por que existem diferenças entre webui e implantação de homepage. Poderíamos enviar as imagens da interface do usuário da web para nosso registro privado, o que deve resolver as questões?

O envio para docker.com pode ser feito manualmente por enquanto (para os lançamentos). Mas automatizar isso seria muito apreciado.

@omnidan Você já nos adicionou ao hub.docker.com? Nome de usuário: markus2330

as novas imagens do docker divididas (aquelas que executam apenas 1 processo) podem ser construídas, enviadas por push e implementadas de forma idêntica à página inicial. provavelmente.

@ markus2330 Eu adicionei você como proprietário, você deve ser capaz de adicionar novos membros em https://hub.docker.com/u/elektra/dashboard/teams/?team=owners agora

Eu diria que mantemos webui.libelektra.org para ter a imagem Docker pública.

E webdemo.libelektra.org é reconstruído a cada commit no master.

@ingwinlu O que você acha?

Eu mudei para webdemo.libelektra.org no # 2110 PR

Acho que podemos fechar isso agora?

@omnidan Você também pode atualizar a página inicial? O "Próximo:" agora é mais verdadeiro: sorria: (a captura de tela também pode ser melhorada.)

Bom trabalho de vocês dois, obrigado!

@ markus2330 sim, podemos fechar isso. Amanhã enviarei a você um RP rápido da homepage!

Obrigado a ambos também, especialmente a @ingwinlu por explicar o docker e jenkins para mim e corrigir meus dockerfiles (aprendi muito sobre o docker com você!)