Added tini as init process to all airflow images. (#176) #209
Conversation
| @@ -31,6 +31,12 @@ ARG MARIADB_RPM_DEVEL_ARM_CHECKSUM=a49c1402378581ba2d63d97daa4a4c04 | |||
| ARG MARIADB_RPM_SHARED_PREFIX=MariaDB-shared-11.4.3-1.fc38 | |||
| ARG MARIADB_RPM_SHARED_X86_CHECKSUM=26a6c7fb021c09b85c21ec1878c1953f | |||
| ARG MARIADB_RPM_SHARED_ARM_CHECKSUM=fd2ce395bf7d2cb959495bbd02ffec2e | |||
| ARG TINI_DOWNLOAD_BASE_URL=https://github.com/krallin/tini/releases/download/v0.19.0/ | |||
There was a problem hiding this comment.
Wondering if ECS fargate provides a direct way to run init process. I see mention of initProcessEnabled in task definition parameters here.
There was a problem hiding this comment.
initProcessEnabled is specific to ECS fargate. However, instances of these images can be deployed to any hosts. But looks like we can use init key in docker compose file that will automatically do the installation instead of doing that via shell. I will make the changes accordingly. Thanks.
There was a problem hiding this comment.
In generally, I like the idea of using tini directly in the image so that customers can pull our image and not worry about init process, plus you get guaranteed parity with how it is running on MWAA.
However, my concern here is pulling from github during image build, at least for the MWAA use-case. I think we need a mechanism to be able to pull from some internal source / trusted vendor to avoid supply chain exposure.
Othewise, maybe we opt to use the built-in tini with docker
| @@ -31,6 +31,12 @@ ARG MARIADB_RPM_DEVEL_ARM_CHECKSUM=a49c1402378581ba2d63d97daa4a4c04 | |||
| ARG MARIADB_RPM_SHARED_PREFIX=MariaDB-shared-11.4.3-1.fc38 | |||
| ARG MARIADB_RPM_SHARED_X86_CHECKSUM=26a6c7fb021c09b85c21ec1878c1953f | |||
| ARG MARIADB_RPM_SHARED_ARM_CHECKSUM=fd2ce395bf7d2cb959495bbd02ffec2e | |||
| ARG TINI_DOWNLOAD_BASE_URL=https://github.com/krallin/tini/releases/download/v0.19.0/ | |||
There was a problem hiding this comment.
In generally, I like the idea of using tini directly in the image so that customers can pull our image and not worry about init process, plus you get guaranteed parity with how it is running on MWAA.
However, my concern here is pulling from github during image build, at least for the MWAA use-case. I think we need a mechanism to be able to pull from some internal source / trusted vendor to avoid supply chain exposure.
Othewise, maybe we opt to use the built-in tini with docker
Issue #, if available: #176
Description of changes:
Dockerfile.base.j2file to include necessary url components to downloadtini.Dockerfile.derivatives.j2, set the container entrypoint to usetinias init system and launches MWAA's Python entrypoint module.tiniinstallation and permissions setup in001-init.shscript.Description of testing:
/proc/1/status.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.