Example how to include Kaniko image build to workflow when runner running on managed container environment
As tested in Hi-Fi/image-build-on-managed-app-services, building of image is possible at managed container environments (in the example AWS Elastic Container Service (ECS)).
Open issue still was left, how this kind of build could be included in GitHub Actions workflow. Some options considered:
- Include Kaniko to same image with runner; This partially works, but can create strange issues as Kaniko would be overwriting whole running container's filesystem
- At least if there's step after image build, runner process fails as it's log file disappears
- Fake somehow the root directory in a way that Kaniko would think that it's working in root while actual directory is something else
- Currently no option found that would work with the limited capabilities offered
- Trigger separate task from runner's task and follow execution of that.
- Creates double costs for some time
| Area / Service | Elastic Container Service | Azure Container Apps | Google Cloud Run |
|---|---|---|---|
| Specific service | ECS Tasks with Fargate | ACA Jobs with Consumption only / Consumption workload profile | Google Cloud Run Jobs |
| Scaling | Custom solution needed, no in-built automated way to scale runners on when needed | Utilizes KEDA, simple scaling of runners | Custom solution needed, no in-built automated way to scale runners on when needed |
| Actions Service | CDKTF code deployes autoscaler that uses same approach than ARC | Upcoming | Upcoming |
| Storage | Ephemeral default 20GiB, max 200 GiB | Ephemeral 1-8 GiB depending on CPU count | In-memory inside runner instance |
| Price region | Europe (Stockholm), eu-north-1 | Sweden Central | Tier 1 |
| Price, vCPU | $0.0445/hour | $0.0864/hour | $0.0648/hour |
| Price, memory | $0.0049/GiB-hour | $0.0108/GiB-hour | $0.0072/GiB-hour |
| Free tier | None | 180,000 vCPU-seconds and 360,000 GiB-seconds | 240,000 vCPU-seconds and 450,000 GiB-seconds |
| Other notes | No possibility to sudo; resulting error with same image that works with ECS. sudo: The "no new privileges" flag is set, which prevents sudo from running as root.sudo: If sudo is running in a container, you may need to adjust the container configuration to disable the flag. |
Kaniko's DNS resolving doesn't work, but required some resolv.conf hacks |
All environments can scale the runners using autoscaler app in this repo. Also example deployments use that one.