Desculpe pela resposta tardia. Eu acredito que a maneira como você descreve o recurso é um pouco técnica demais aqui, na verdade eu nem entendi o caso de uso por trás disso. Você poderia me dar mais detalhes funcionais sobre o que você gostaria de alcançar?

O objetivo desta solicitação é ser capaz de atualizar automaticamente os serviços em execução gerenciados pelo Portainer quando sua imagem correspondente é atualizada (criada ou enviada) no registro (como DockerHub).

Meu primeiro post descreve uma abordagem potencial para implementá-lo de forma segura. Ele utiliza webhooks da mesma forma que compilações automatizadas no DockerHub são notificadas pelo GitHub / Bitbucket associado para acionar uma nova compilação. O DockerHub também tem a opção de configurar webhooks que executarão ping em quaisquer URLs especificados nele quando uma imagem for atualizada. Podemos aproveitar isso para implementar esse recurso.

Informe-nos se precisar de mais explicações sobre partes específicas.

Ah, então uma experiência de “torre de vigia” integrada ...

Rgds,

Neil Cresswell

Em 26/02/2018, às 15:25, Sawood Alam < [email protected] [email protected] > escreveu:

O objetivo desta solicitação é ser capaz de atualizar automaticamente os serviços em execução gerenciados pelo Portainer quando sua imagem correspondente é atualizada (criada ou enviada) no registro (como DockerHub).

Meu primeiro post descreve uma abordagem potencial para implementá-lo de forma segura. Ele utiliza webhooks da mesma forma que compilações automatizadas no DockerHub são notificadas pelo GitHub / Bitbucket associado para acionar uma nova compilação. O DockerHub também tem a opção de configurar webhooks que executarão ping em quaisquer URLs especificados nele quando uma imagem for atualizada. Podemos aproveitar isso para implementar esse recurso.

Informe-nos se precisar de mais explicações sobre partes específicas.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, vê-lo no GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_portainer_portainer_issues_1663-23issuecomment-2D368372154&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=1nvAiOGea4FI3fcdhFf-8_qK4mfCCBx6tCL6UNPoFQA&s= Ys81d7Tm_31bM7JtEmThReyWJautlF-iTVe1x233E8Y & e = , ou silenciar o fio https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AWGrlSK983MIrpcawUH3aKts9Myil3INks5tYhXwgaJpZM4SMts1&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=1nvAiOGea4FI3fcdhFf-8_qK4mfCCBx6tCL6UNPoFQA&s=9VEw6zb4ZqgbyM9_OyBEe-lrh0LA1pcWim -2El90RAE & e = .

Meio relacionado a https://github.com/portainer/portainer/issues/1304

Sim, está relacionado ao # 1304, mas descreve um mecanismo de implementação que utiliza o recurso de webhook (ou em outras palavras, notificação ou pingback) de registros ou outros sistemas CI / CD em vez de usar pesquisas periódicas que podem ser inúteis ou atrasadas.

É como a funcionalidade de reimplantação automática do Docker Cloud, e eu só posso 👍. Com o fechamento do Docker Cloud, muitas pessoas buscarão uma alternativa ... e estão agora. Veja o último parágrafo aqui https://docs.docker.com/docker-cloud/migration/#what -stays-the-same

Eu preciso desse recurso!

Também gostamos de ver esse recurso.

Nossa configuração atual com docker cloud:

1. Impulsionamos nosso projeto no github
2. O hub do Docker cria automaticamente uma nova imagem
3. A nuvem Docker reimplantou nossas imagens se isso foi configurado dessa forma

Usamos essa configuração para nosso desenvolvimento.
Temos um branch de desenvolvimento que constrói e reimplanta automaticamente no git push
Quando nos unimos a um teste, isso também cria e reimplanta automaticamente
Quando mesclamos o teste com a produção (mestre), ele é automaticamente compilado, mas nós

Com o portainer atual, precisamos puxar a imagem mais recente na página de imagens e depois disso precisamos ir para o serviço e atualizar o serviço.

Voltei para verificar se há algum progresso neste pedido. Fiquei surpreso ao ver o número de polegares para a primeira postagem, mas ninguém parece estar interessado em trabalhar nisso. Embora eu tenha um entendimento arquitetônico de como esse recurso pode ser implementado (conforme descrito no primeiro post), não estou familiarizado com a base de código do Portainer e, nos próximos meses, algumas outras prioridades vão manter minhas mãos atadas. Porém, eu realmente gostaria que alguém pudesse cuidar disso logo. Terei todo o prazer em discutir os detalhes da implementação, se necessário.

Na verdade, eu atribuí isso a um de nossos desenvolvedores para criar uma especificação funcional e me dar uma estimativa para o esforço de desenvolvimento.

Assista esse espaço..

De: Sawood Alam [email protected]
Enviado: quarta-feira, 27 de junho de 2018 12h39
Para: portainer / portainer [email protected]
Cc: Neil Cresswell [email protected] ; Comentário [email protected]
Assunto: Re: [portainer / portainer] [Solicitação de recurso] Automatizar a implantação usando webhooks de registro (# 1663)

Voltei para verificar se há algum progresso neste pedido. Fiquei surpreso ao ver o número de polegares para a primeira postagem, mas ninguém parece estar interessado em trabalhar nisso. Embora eu tenha um entendimento arquitetônico de como esse recurso pode ser implementado (conforme descrito no primeiro post), não estou familiarizado com a base de código do Portainer e, nos próximos meses, algumas outras prioridades vão manter minhas mãos atadas. Porém, eu realmente gostaria que alguém pudesse cuidar disso logo. Terei todo o prazer em discutir os detalhes da implementação, se necessário.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, vê-lo no GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_portainer_portainer_issues_1663-23issuecomment-2D400506423&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=s5UOJA0LMQhYo4cJoPJMCabVMZ7GXSrYR8W6DLyAWvk&s=uKaL_Difg8k_Uy1LtTzNyAXVR3tVsxJ_oYWf7EN4kHA&e= , ou silenciar o fio https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AWGrlXbQhPQW3bKQTmCXKNq6unPoUY5bks5uAtQGgaJpZM4SMts1&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=s5UOJA0LMQhYo4cJoPJMCabVMZ7GXSrYR8W6DLyAWvk&s=O6uss9ua_UOTYRVDl6pNSsJgeeCx_4f3_4cWV4YCJo0&e= .

Para sua informação, aqui está o primeiro esboço das especificações:

Recurso de reimplantar serviço

O Portainer pode expor uma nova API de webhook que pode ser usada para acionar uma atualização de serviços específicos.

Notas:

• esta especificação apenas descreve como associar um webhook a um serviço Swarm (para pilhas Swarm, cada serviço da pilha pode ser atualizado independentemente por meio da visualização de detalhes do serviço). Poderíamos potencialmente adicionar o mesmo comportamento aos contêineres, mas devemos começar com os serviços primeiro.
• pode ser interessante brincar com https://github.com/imjosh/docker-deploy-webhook para obter alguns insights extras.

Portainer UI (frontend)

Nas visualizações de criação de serviço / detalhes de serviço, uma nova opção "Criar webhook de reimplantação" é adicionada.

Quando ativado, após a criação bem-sucedida do serviço, uma solicitação HTTP POST é enviada para / api / webhooks (política de usuário autenticado) com a seguinte carga útil:

serviceId: docker service identifier of the service,
endpointId: endpoint identifier where the service is located

API Portainer (backend)

A solicitação anterior criará um novo objeto webhook:

id: webhook identifier,
serviceId: docker service identifier,
endpointId: endpoint identifier where the service is located

O webhook pode ser usado enviando uma solicitação HTTP POST para api / webhook /: id (política de acesso público para ser acessado a partir de serviços externos, como DockerHub)

Não requer carga útil.

Observação: como o ponto de extremidade / api / webhook /: id é exposto publicamente, o formato do identificador do webhook deve estar na forma de uma string gerada aleatoriamente. Podemos querer adicionar um parâmetro de consulta extra que pode corresponder à restrição de acesso.

Ao receber uma solicitação POST em / api / webhook /: id, a API enviará uma solicitação ao endpoint especificado para recuperar detalhes sobre o serviço associado ao webhook (usando o identificador de serviço). Ele extrairá informações sobre a imagem usada nos detalhes do serviço, recuperará quaisquer detalhes de autenticação do registro, se necessário (verificar no banco de dados) e enviará uma solicitação de atualização do serviço.

Nota: Para executar solicitações Docker do back-end, provavelmente precisaremos incorporar o Docker SDK dentro da API para permitir que o back-end atue como um cliente Docker.

No hub do Docker, você pode criar um Webhook
https://docs.docker.com/docker-hub/webhooks/ que aciona uma pós-chamada sempre que uma imagem é criada ou uma tag é adicionada.
Portanto, poderíamos acionar um pull de imagem e reimplantar no portainer.

@Cinezaster esse é o objetivo, sim

@deviantony nunca usamos a visão de criação de serviço para criar nosso serviço, mas, em vez disso, usamos um stackfile para criar nosso serviço, seria possível adicionar o webhook posteriormente por meio da visão de serviço?

Sim, você também poderá acessar a visualização de detalhes do serviço para criar um webhook de reimplantação. Atualizarei as especificações.

Alguma notícia sobre este pedido?

Sim, ainda está em nossa lista de prioridades, vou designar alguém nisso em breve.

PARA SUA INFORMAÇÃO. Não é totalmente a mesma coisa, mas pode ser útil para alguns usuários. Acabei de publicar minha extensão do Portainer para VSTS: https://marketplace.visualstudio.com/items?itemName=OlliJanatuinen.portainer-deploy

Alguém está interessado em experimentar a implementação para isso? Está disponível através de portainer/portainer:feat1663-add-webhook (Linux amd64 build apenas).

Qualquer feedback é bem-vindo!

@deviantony vamos tentar e testar @appsaloon

Isso é apenas para serviços de enxame ou também para contêineres independentes?

@ Strum355 apenas para serviços Swarm agora.

Ah, não se preocupe, há um eta difícil quando podemos ver isso para os contêineres?

Ainda sem ETA

Obrigado por avançar com este. Acabei de implantá-lo e agora explorando ao redor. Fornecerei mais feedback no PR # 2161.

Devemos também planejar generalizar essa funcionalidade de webhook para outras entidades (como descrevi brevemente em um comentário anterior) e torná-la uma entidade de primeira classe para ser exibida no menu da barra lateral? Uma extensão imediata em que posso pensar são os webhooks para imagens que nos permitiriam nos conectar diretamente de um repositório de origem (como um no GitHub ou BitBucket) e construir uma imagem diretamente (que é possível graças ao # 1667) quando o código muda . Opcionalmente, também podemos atualizar serviços / contêineres quando uma imagem associada é atualizada localmente.

Se decidirmos fazer webhooks para mais de uma entidade, podemos usar o namespace de URLs como https://portainer.example.com/api/webhooks/services/12345... e https://portainer.example.com/api/webhooks/images/12345... vez de https://portainer.example.com/api/webhooks/12345... .

Embora não seja necessário, pois os IDs de gancho podem ser exclusivos em todo o sistema e seu tipo associado pode ser armazenado em uma tabela na forma de associação polimórfica.

@Cinezaster e eu
Mas as tags das imagens que foram atualizadas estão todas <none> , tanto na lista de imagens no portainer quanto quando vejo docker images . No entanto, isso não interfere na funcionalidade. Temos vários serviços usando a mesma imagem com tags diferentes, e todos eles ainda estão usando a imagem correta após a atualização.

Assim que o desenvolvimento estiver concluído, precisamos de alguém para documentar / blogar como vincular o portainer a webhooks dockerhub como você fez, gostaria de ser um voluntário para isso?

Rgds,

Neil Cresswell

Em 27/08/2018, às 16h37, Jo Jordens < [email protected] [email protected] > escreveu:

@Cinezaster https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Cinezaster&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=Ppw5k5PG1o8Dc0s32b3QQRfKWrl25HEvMc5Jx0-8vrY&s=TqOWOtwxUrb9DhaLtaZGfZ_4zCYlwaTMfGzIvtX0QtE&e= e eu tentei sair com o hub webhooks. docker fornece. E funciona, nossos serviços são atualizados automaticamente após cada envio para um repositório.
Mas as tags das imagens que foram atualizadas são todas, tanto na lista de imagens no portainer quanto quando vejo as imagens do docker. No entanto, isso não interfere na funcionalidade. Temos vários serviços usando a mesma imagem com tags diferentes, e todos eles ainda estão usando a imagem correta após a atualização.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, vê-lo no GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_portainer_portainer_issues_1663-23issuecomment-2D416172189&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=Ppw5k5PG1o8Dc0s32b3QQRfKWrl25HEvMc5Jx0-8vrY&s= 0UKZwz1EI0L8JYdLqrswGx6dpZ0DT9QlxD_aXH-N6vE & e = , ou silenciar o fio https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AWGrlVGGU2TyMZz2ErAk-5FseDNYgftzE5ks5uU73VgaJpZM4SMts1&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=Ppw5k5PG1o8Dc0s32b3QQRfKWrl25HEvMc5Jx0-8vrY&s=ofElX8u3XOItT169JEYAQ0UO8f6moEEEoBWaOqBJCMU&e =

Algum feedback dos usuários que puderam testar isso ainda?

@deviantony , @JoJordens testou o recurso, seu único comentário: as tags das imagens são <none> após uma atualização.
@ncresswell Vamos escrever uma postagem no blog nesta ou na próxima semana sobre como usar esse recurso.

Eu também tenho testado isso e fornecido comentários sobre a funcionalidade e o código.

• Devemos criar um namespace de URIs de webhook (incluindo services no URI para estender a funcionalidade a outros aspectos, como images no futuro)?
• Acho que o problema da tag <none> está presente na funcionalidade da pilha. Quando uma pilha é implantada / atualizada sem primeiro atualizar a imagem explicitamente, a imagem puxada não é marcada corretamente. Eu tenho visto esse problema há muito tempo.
• Como não estamos utilizando nenhuma carga útil do pingback do webhook, também devemos fazer com que funcione em uma solicitação GET e não apenas em uma solicitação POST? O ideal é que os webhooks sejam uma solicitação PUT, mas os sistemas existentes a enviam via POST, portanto, fazer com que funcione no POST é importante. No entanto, o suporte a GET será mais conveniente para acionar uma atualização a partir da linha de comando.

Obrigado @Cinezaster

Também obrigado @ibnesayeed, mas eu estava esperando um feedback de UI / UX :-)

Em relação aos seus pontos técnicos:

Devemos usar o namespace de URIs de webhook (incluindo serviços no URI para estender a funcionalidade a outros aspectos, como imagens no futuro)?

Acho que não, mas estenderemos o objeto Webhook para oferecer suporte a um novo campo Type.

Eu acho que oproblema de tag está presente na funcionalidade da pilha. Quando uma pilha é implantada / atualizada sem primeiro atualizar a imagem explicitamente, a imagem puxada não é marcada corretamente. Eu tenho visto esse problema há muito tempo.

Sim, este é um problema conhecido.

Como não estamos utilizando nenhuma carga útil do pingback do webhook, também devemos fazer com que funcione em uma solicitação GET e não apenas em uma solicitação POST? O ideal é que os webhooks sejam uma solicitação PUT, mas os sistemas existentes a enviam via POST, portanto, fazer com que funcione no POST é importante. No entanto, o suporte a GET será mais conveniente para acionar uma atualização a partir da linha de comando.

Como a maioria dos sistemas está enviando solicitações POST, acredito que devemos mantê-lo assim. Embora uma solicitação GET seja mais conveniente por meio da CLI, não é muito complicado enviar uma solicitação POST, então não acho que vamos querer oferecer suporte a solicitações GET também.

No lado da IU, inicialmente pensei que poderíamos adicionar o botão de alternância na lista tabular de serviços, seja na página principal de serviços ou em uma pilha específica. No entanto, acho que adicionar apenas a opção é insuficiente. Portanto, se fizermos isso, precisaremos ter mais elementos de IU para expor o URI do webhook (possivelmente na gaveta que aparece quando uma linha de serviço é clicada).

Acho que não, mas estenderemos o objeto Webhook para oferecer suporte a um novo campo Type.

Contanto que extensões futuras não sejam interrompidas, tudo bem. Eu apenas apontei para que possamos torná-lo à prova de futuro.

Sim, este é um problema conhecido.

Temos um tíquete para rastrear esse problema?

Como a maioria dos sistemas está enviando solicitações POST, acredito que devemos mantê-lo assim. Embora uma solicitação GET seja mais conveniente por meio da CLI, não é muito complicado enviar uma solicitação POST, então não acho que vamos querer oferecer suporte a solicitações GET também.

Estou bem com isso. Não sou um grande fã de ter muitas maneiras de fazer a mesma coisa, mas achei que poderia ser útil para alguns.

@ibnesayeed veja https://github.com/portainer/portainer/issues/1486

@kendrickm , eu puxei a última imagem portainer:feat1663-add-webhook alguns minutos atrás após seus commits recentes e reimplantei a pilha em meu servidor. Agora, meus webhooks existentes estão quebrados. Todos os serviços em que habilitei webhooks agora parecem ter desabilitado webhooks associados. Se eu tento enviar uma solicitação POST para um webhook que foi criado anteriormente, obtenho um código de resposta 500 e se eu envio uma solicitação para um aleatório inexistente, obtenho um 502. Acho que podemos melhorar os códigos de status aqui , dependendo da situação.

Acho que o motivo tem a ver com o campo de tipo de webhook recém-adicionado, que não é preenchido para tokens existentes. Em caso afirmativo, há uma maneira de corrigir o banco de dados em minha instância em execução, pois não gostaria de recriar todos esses tokens e atualizar registros no DockerHub para todos os repositórios associados.

$ curl -X POST -i https://portainer.example.com/api/webhooks/<created-earlier-but-now-hidden-token>
HTTP/1.1 500 Internal Server Error
Content-Length: 102
Content-Type: application/json
Date: Thu, 30 Aug 2018 21:23:15 GMT
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block

{"err":"Unsupported webhook type","details":"Webhooks for this resource are not currently supported"}

$ curl -X POST -i https://portainer.example.com/api/webhooks/<non-existing-random-token>
HTTP/1.1 502 Bad Gateway
Date: Thu, 30 Aug 2018 21:23:21 GMT
Content-Length: 11
Content-Type: text/plain; charset=utf-8

Bad Gateway

Consegui consertar minha implantação editando manualmente o arquivo de banco de dados Bolt usando https://github.com/br0xen/boltbrowser.

@ibnesayeed Sim, houve um bug em torno do tratamento de erros, causando um segfault vs retornar um erro real. Você está usando um proxy de servidor da web na frente dele?

Você está usando um proxy de servidor da web na frente dele?

Sim, estou usando o Traefik como proxy reverso na frente da minha instância do Portainer e tudo mais.

Embora eu esteja muito feliz com o fato de esse recurso estar prestes a ser mesclado, pensei que seria útil ter a capacidade de personalizar opcionalmente o token? Posso pensar em alguns lugares onde se pode ter algum esquema de nomenclatura para esses tokens para automatizar o processamento em lote sem essencialmente consultar todos os serviços e seus tokens associados. No lado da IU, podemos adicionar um botão ao lado do botão Copiar link que diz "Personalizar token" ou "Personalizar token". Talvez possamos ter um token gerado aleatoriamente que tenha um alias personalizado opcional.

@ibnesayeed podemos abrir uma nova solicitação de aprimoramento mais tarde para isso.

@ibnesayeed podemos abrir uma nova solicitação de aprimoramento mais tarde para isso.

Sim eu concordo. Eu não tive a intenção de atrasar o PR correspondente, mas compartilhar meus pensamentos.

@ibnesayeed all good,

Estou assumindo que uma nova solicitação de aprimoramento deve ser feita para ter implantação automatizada para contêineres individuais?

Sim @ Strum355

# 2236 aberto para rastrear o recurso de token personalizado.

Isso é compatível com o Windows?

@goalbased Não vejo nenhuma razão para que não funcione no Windows. Você pode testar e informar o uso?

Não consigo encontrar a guia Serviço, alguma ideia? Eu preciso do Swarm ou algo assim primeiro?

@goalbased Ele só existe quando o modo Swarm está habilitado e isso é devido à forma como o Docker funciona.

Por favor, junte-se ao Portainer Slack e faça essas perguntas off-topic lá.