Skip to content

Conversation

@chaptersix
Copy link
Contributor

@chaptersix chaptersix commented Nov 20, 2025

What changed?

This PR ports the Docker image building process from temporalio/docker-builds into this repository. For images built from version 1.30.0 and later, the number of dependencies has been reduced.

This PR focuses on the Dockerfiles and local build tooling. Future PRs will add GitHub Actions for automated builds.

Changes Made

  • Added Dockerfiles and supporting shell scripts for server and admin-tools images (both standard and legacy variants)
  • Added docker-bake.hcl configuration for building images
  • Added Makefile and helper scripts (these will likely be removed in future PRs once GitHub Actions are in place)

Note: Legacy targets (legacy-server, legacy-admin-tools) are for server versions 1.26.0 -> 1.29.X (X being the highest supported version) and can be removed once support for those versions is no longer needed.

Why?

The existing build process is more complex than it has to be and existing images have dependencies that are not necessary.

How did you test it?

  • run new images with the helm-charts
  • run legacy images with the helm-charts
  • run new images with docker compose
  • run legacy images with docker compose

Potential risks

Some users might depend on some of the dependencies we've included in our images until now. Or there some special case that we haven't taken into account.

@chaptersix chaptersix marked this pull request as ready for review November 21, 2025 12:21
@chaptersix chaptersix requested review from a team as code owners November 21, 2025 12:21
@chaptersix chaptersix requested a review from bergundy November 21, 2025 13:25
Copy link
Member

@bergundy bergundy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I skimmed this and added some comments.

@@ -0,0 +1,33 @@
ARG ALPINE_IMAGE=alpine:3.22@sha256:4b7ce07002c69e8f3d704a9c5d6fd3053be500b7f1c69fc0d80990c2ad8dd412
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this need to be an arg?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we can update it when doing security updates. I was planning on allowing the a workflow run to define it so we don't have to edit the github tag with the latest alpine tag.

RUN addgroup -g 1000 temporal && \
adduser -u 1000 -G temporal -D temporal && \
mkdir -p /etc/temporal/config/dynamicconfig && \
touch /etc/temporal/config/dynamicconfig/docker.yaml && \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to be called docker.yaml?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, the normal config defines the path so we can change it.


RUN addgroup -g 1000 temporal && \
adduser -u 1000 -G temporal -D temporal && \
mkdir -p /etc/temporal/config/dynamicconfig && \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/etc is already for config files, why do we need the extra /config and /dynamicconfig dirs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was keeping the existing pattern since the helm-charts writes to this config directory. I assume it has to exist in the image but will double check.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder how much of this can be cleaned up.

Copy link
Contributor Author

@chaptersix chaptersix Nov 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked into it briefly

  1. TEMPORAL_BROADCAST_ADDRESS is needed so the server knows what addresses to broadcast for ringpop. I don't believe 0.0.0.0 is sufficient
  2. You have to specify the port for IPv4 and IPv6 differently.
  3. It's possible to have multiple network interfaces for so BIND_ON_IP is needed. The interface the server is binding should be the same as what it's board casting

I'll look and see if the server itself is able to handle this in some way. I found some config that controls whether or not the server binds on localhost in the dynamic or normal config.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can just set good defaults for the embedded config and make sure helm has a valued. I'll make sure to include something about this in the release notes.
Removed all scripts from the server image

@chaptersix chaptersix mentioned this pull request Nov 25, 2025
2 tasks
@chaptersix chaptersix marked this pull request as draft November 25, 2025 21:43
@chaptersix
Copy link
Contributor Author

The makefile and build scripts will be removed In a future PR. Just here for demo/testing.

The Alpine Image is an argument so we can trigger builds via workflows without committing to given branch. It should make re-building images easier

@chaptersix chaptersix marked this pull request as ready for review November 26, 2025 00:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants