Problemas para criar volumes relacionados ao component_path ao tentar executar tasks docker

[jeffersoncandidozup]

O que aconteceu:

Ao tentar utilizar a action da STK CLI em um job do Github actions, tive problemas pois a ferramenta não está conseguindo criar volumes relacionados ao path da task. Tal feature foi testada em mais de uma máquina e acredita-se que o problema está relacionado a permissionamento de leitura e escrita no SO da runner.

O que você esperava que acontecesse:

Ao importar a stack e tentar utilizar a task, o comportamento esperado era que a task conseguisse realizar o pull da imagem docker configurada (ok), montar alguns volumes relacionados a arquivos contidos na task (not ok) e no repositório (ok) e executar a aplicação (not ok).

Como reproduzi-lo (o mínimo e preciso possível):

• Passo 1: Criar uma task docker utilizando qualquer imagem base
• Passo 2: Criar algum script/package na raiz da task;
• Passo 3: Configurar no arquivo task.yaml a montagem de um volume que viabilize a utilização do script/package criado no Passo 2 de dentro do container da task;
• Passo 4: Criar um workflow do Github Actions para executar os comandos necessários para execução da task docker;
• Passo 5: Executar o workflow e verificar que o script não será encontrado de dentro do container.

Algo mais que precisamos saber?

Alguns detalhes sobre o problema que tive e um workaround que apliquei para conseguir utilizar a task.

A task está commitada no diretório do seguinte repositório: https://github.com/stack-spot/data-stack/tree/main/tasks/generate-avro-schema-from-json

Essa task foi criada utilizando docker justamente por se tratar de um tipo de aplicação que demanda um pouco mais de tempo para execução e isso prejudicaria um pouco a experiencia do usuário se ele fosse executar localmente. Por isso, colocamos a execução nesta pipeline.

A aplicação que é executada trata-se de um job Apache Spark utilizado para a criação de schemas avro a partir da amostra de eventos das aplicações do usuário.

Sendo assim, foi necessário criar uma pasta com a package Python (app/src, o job Spark pode ser escrito em Python utilizando a biblioteca PySpark), outra para arquivos de configuração (app/conf) e outra para binários necessários ao job (app/jars).

Dessa forma, os volumes necessários para a execução da task foram configurados conforme imagem a seguir:

Ao executar a task no workflow, houve falha com a mensagem de que o script principal da aplicação Spark não foi encontrado dentro do container:

Em uma tentativa de entender melhor o ocorrido, foram colocadas algumas linhas de comandos para tentar entender o porque de o arquivo não estar presente no container docker e pode-se observar que as pastas src e jars não foram montadas pelo volume.

Para tentar não ficar travado por esse problema, foi realizado um workaround da seguinte forma:

O repositório da stack foi clonado diretamente para uma pasta dentro do workspace da runner, pois o path da stack ao ser importada estava no diretório /home/runner/.stk/stacks/data-stack e os arquivos do diretório que não tiveram problema de montagem de volume estavam no diretório /runner/_work/stackspot-data-platform-pipeline

Ao realizar o clone da stack para a pasta /runner/_work/data-stack e passar a flag task_path no momento da execução da task fez com que o comportamento esperado ocorresse.

https://github.com/stack-spot/stackspot-data-platform-pipeline/blob/1872cb80aa8ce27a417438a5dc61a8442b867dc1/.github/workflows/stk.yaml#L95

O objetivo desta issue é abrir espaço para a discussão do problema apresentado e tentar encontrar possíveis soluções para que os usuários da cli consigam utilizar esta action sem a necessidade de se preocupar com problemas em tasks que precisarão criar volumes relacionados ao path do próprio componente.

Ambiente:

• Versão do projeto: N/A
• Sistema operacional: Linux
• Outros: N/A