[WIP] Optimize docker image#628
Conversation
📝 WalkthroughUpdated Docker and compose configurations to use leaner runtime images and slimmer service checks. The changes remove unused packages across Alpine, Rocky, and Ubuntu Dockerfiles, replace some download steps with simpler tooling, and tighten final cleanup steps to reduce image footprint. Related compose health checks were also simplified to use basic TCP connectivity checks instead of HTTP endpoint probes. Image references were refreshed from the older Docker registry paths to the newer registry locations where applicable. WalkthroughAcross all image variants (Alpine, Rocky Linux, Ubuntu) and docker-compose configurations, this change removes 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docker-compose/apim-is-as-km-with-analytics/docker-compose.yml`:
- Line 39: The current healthcheck only verifies that the port is open, which
can mark the service healthy too early. Update the healthcheck for the
`is-as-km` and `api-manager` services to use an application-level HTTP(S)
readiness probe instead of the TCP-only `bash -c "exec 3<>/dev/tcp/..."` check,
so dependent services gated by `service_healthy` wait for the actual endpoints
to be ready. Use the existing healthcheck definitions in the compose file and
keep the readiness logic tied to each service’s protocol-level endpoint.
In `@docker-compose/apim-with-analytics/docker-compose.yml`:
- Line 39: The healthcheck for the API Manager service is only doing a raw TCP
socket check, which is too weak to prove readiness. Update the healthcheck to
use an application-level probe in the relevant docker-compose service definition
so it verifies an HTTP endpoint or similar readiness signal instead of just
connecting to localhost:9763, and keep the change tied to the existing
healthcheck configuration for that service.
In `@docker-compose/apim-with-mi/docker-compose.yml`:
- Line 39: The `api-manager` healthcheck was weakened to a raw TCP port check,
which can report healthy before the service is actually ready. Update the
`healthcheck.test` for `api-manager` in the docker-compose setup to use a real
HTTP readiness probe again, so `micro-integrator` waiting on `service_healthy`
only proceeds when `api-manager` is truly ready.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a7470d26-88f0-40e0-8b74-b2a8a9c3f132
📒 Files selected for processing (15)
docker-compose/apim-is-as-km-with-analytics/docker-compose.ymldocker-compose/apim-with-analytics/docker-compose.ymldocker-compose/apim-with-mi/docker-compose.ymldockerfiles/alpine/apim-acp/Dockerfiledockerfiles/alpine/apim-tm/Dockerfiledockerfiles/alpine/apim-universal-gw/Dockerfiledockerfiles/alpine/apim/Dockerfiledockerfiles/rocky/apim-acp/Dockerfiledockerfiles/rocky/apim-tm/Dockerfiledockerfiles/rocky/apim-universal-gw/Dockerfiledockerfiles/rocky/apim/Dockerfiledockerfiles/ubuntu/apim-acp/Dockerfiledockerfiles/ubuntu/apim-tm/Dockerfiledockerfiles/ubuntu/apim-universal-gw/Dockerfiledockerfiles/ubuntu/apim/Dockerfile
| build: ./dockerfiles/is-as-km | ||
| healthcheck: | ||
| test: ["CMD", "curl", "-k", "--fail", "https://localhost:9444/api/health-check/v1.0/health"] | ||
| test: ["CMD", "bash", "-c", "exec 3<>/dev/tcp/localhost/9444"] |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Keep application-level readiness checks here.
These probes now only confirm that the port accepts a TCP connection. In this file, service_healthy gates dependent services, so is-as-km and api-manager can be marked healthy before their HTTP(S) endpoints are actually ready. Please keep a protocol-level readiness check for these services.
Also applies to: 53-53
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/apim-is-as-km-with-analytics/docker-compose.yml` at line 39,
The current healthcheck only verifies that the port is open, which can mark the
service healthy too early. Update the healthcheck for the `is-as-km` and
`api-manager` services to use an application-level HTTP(S) readiness probe
instead of the TCP-only `bash -c "exec 3<>/dev/tcp/..."` check, so dependent
services gated by `service_healthy` wait for the actual endpoints to be ready.
Use the existing healthcheck definitions in the compose file and keep the
readiness logic tied to each service’s protocol-level endpoint.
| build: ./dockerfiles/apim | ||
| healthcheck: | ||
| test: ["CMD", "curl", "--fail", "http://localhost:9763/services/Version"] | ||
| test: ["CMD", "bash", "-c", "exec 3<>/dev/tcp/localhost/9763"] |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
This healthcheck is now too weak for readiness.
A successful TCP connect does not prove the API Manager is ready to serve requests. This can report the container healthy while the HTTP endpoint is still starting up. Please keep an application-level readiness probe instead of a raw socket check.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/apim-with-analytics/docker-compose.yml` at line 39, The
healthcheck for the API Manager service is only doing a raw TCP socket check,
which is too weak to prove readiness. Update the healthcheck to use an
application-level probe in the relevant docker-compose service definition so it
verifies an HTTP endpoint or similar readiness signal instead of just connecting
to localhost:9763, and keep the change tied to the existing healthcheck
configuration for that service.
| build: ./dockerfiles/apim | ||
| healthcheck: | ||
| test: ["CMD", "curl", "--fail", "http://localhost:9763/services/Version"] | ||
| test: ["CMD", "bash", "-c", "exec 3<>/dev/tcp/localhost/9763"] |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Keep a real readiness probe for api-manager.
This now marks the service healthy as soon as the port is open, which is weaker than the previous HTTP check. Since micro-integrator waits on service_healthy in this file, startup can proceed before api-manager is actually ready.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/apim-with-mi/docker-compose.yml` at line 39, The `api-manager`
healthcheck was weakened to a raw TCP port check, which can report healthy
before the service is actually ready. Update the `healthcheck.test` for
`api-manager` in the docker-compose setup to use a real HTTP readiness probe
again, so `micro-integrator` waiting on `service_healthy` only proceeds when
`api-manager` is truly ready.
1 participant
Purpose
Remove unnecessary dependencies from APIM docker images. We remove unnecessary packages to reduce the image size, minimize the attack surface, and improve the overall security posture of the Docker images.