Support for configuring Gitea from the main container #632

New Issue

NotAndD · 2024-03-19T10:34:58Z

NotAndD commented

2024-03-19 10:34:58 +00:00

Hey everyone!

I was trying to install Gitea on a k8s cluster with Istio injection enabled and using a MySQL database which is hosted inside the cluster itself. Istio adds a sidecar to Pods which handle all the network traffic, handling transparent mutual TLS communication and more, but it has the side effect of creating issues when trying in-cluster network communication from init containers if mTLS is required (plus, MySQL is a server-first protocol so there are a few other issues).

Since the Chart uses a init container to configure Gitea, interacting with the database, I found no way to have it working when Istio is enforcing mTLS to the MySQL database and I had to modify the chart to run /usr/sbin/configure_gitea.sh inside the main container before the main entrypoint.

Wanted to ask if I can provide a pull request for this, or if this issue was already analyzed and there's an alternative solution?

Hey everyone! I was trying to install Gitea on a k8s cluster with Istio injection enabled and using a MySQL database which is hosted inside the cluster itself. Istio adds a sidecar to Pods which handle all the network traffic, handling transparent mutual TLS communication and more, but it has the side effect of creating issues when trying in-cluster network communication from init containers if mTLS is required (plus, MySQL is a server-first protocol so there are a few other issues). Since the Chart uses a init container to configure Gitea, interacting with the database, I found no way to have it working when Istio is enforcing mTLS to the MySQL database and I had to modify the chart to run `/usr/sbin/configure_gitea.sh` inside the main container before the main entrypoint. Wanted to ask if I can provide a pull request for this, or if this issue was already analyzed and there's an alternative solution?

justusbunsi commented

2024-03-19 12:29:39 +00:00

Hi. Thanks for reaching out. There are known issues with using this Helm Chart in pair with Istio. I've filed an issue to rethink the init container usage (#332). Unfortunately, none of us maintainers had enough time yet to redesign the init container usage. It comes with a necessary redesign of the app.ini creation and updating. The app.ini creation needs to be migrated out of the init container phase first, so that Gitea can properly start. Then it can be fine tuned and customized. There are 2 open WIP PRs regarding app.ini redesign: #450 and #544.

If you want to help redesign the init container usage, you are very welcome.

Hi. Thanks for reaching out. There are known issues with using this Helm Chart in pair with Istio. I've filed an issue to rethink the init container usage (#332). Unfortunately, none of us maintainers had enough time yet to redesign the init container usage. It comes with a necessary redesign of the app.ini creation and updating. The app.ini creation needs to be migrated out of the init container phase first, so that Gitea can properly start. Then it can be fine tuned and customized. There are 2 open WIP PRs regarding app.ini redesign: #450 and #544. If you want to help redesign the init container usage, you are very welcome.

NotAndD commented

2024-03-20 10:21:24 +00:00

Actually, I found out an existing solution for this, which solves the problem without requiring any change to the Gitea Helm chart.

Starting from Kubernetes 1.28 a new feature gate was introduced, called SidecarContainers, which is now in beta and enabeld by default in 1.29 version. When enabled, sidecar containers can be scheduled as init containers. This is already supported by Istio under an env variable for now.

I tested it out and it works without issues, configure-gitea can run as init container because Istio sidecar is already available.

Actually, I found out an existing solution for this, which solves the problem without requiring any change to the Gitea Helm chart. Starting from Kubernetes 1.28 a new feature gate was introduced, called `SidecarContainers`, which is now in beta and enabeld by default in 1.29 version. When enabled, sidecar containers can be scheduled as init containers. This is already supported by Istio under an env variable for now. I tested it out and it works without issues, `configure-gitea` can run as init container because Istio sidecar is already available.

justusbunsi commented

2024-03-20 17:43:58 +00:00

That's a neat way. Thanks for sharing and glad you found a solution.

(Moving away from init containers will still be done at some point. Istio was not the main reason for that. 🙂)

That's a neat way. Thanks for sharing and glad you found a solution. (Moving away from init containers will still be done at some point. Istio was not the main reason for that. 🙂)

justusbunsi commented

2024-03-20 17:45:22 +00:00

Do you mind adding your solution to the docs? I guess there will be others having similar issues in the future.

Sign in to join this conversation.

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/helm-chart#632