diff --git a/.github/workflows/pull_request.yaml b/.github/workflows/pull_request.yaml index 01e3dd8..ad12153 100644 --- a/.github/workflows/pull_request.yaml +++ b/.github/workflows/pull_request.yaml @@ -9,11 +9,6 @@ on: - '**' - '!.markdownlint.yaml' - '!.vale.ini' - - '!Dockerfile-docs' - - '!docs-nginx.conf' - - '!docs/**' - - '!theme_common' - - '!theme_override' - '!deployments/kubernetes/chart/reloader/**' env: diff --git a/.github/workflows/pull_request_docs.yaml b/.github/workflows/pull_request_docs.yaml deleted file mode 100644 index 7416237..0000000 --- a/.github/workflows/pull_request_docs.yaml +++ /dev/null @@ -1,34 +0,0 @@ -name: Pull Request for Documentation Changes - -on: - pull_request: - branches: - - master - paths: - - '.markdownlint.yaml' - - '.vale.ini' - - 'Dockerfile-docs' - - 'docs-nginx.conf' - - 'docs/**' - - '!docs/plans/**' - - 'theme_common' - - 'theme_override' - - 'deployments/kubernetes/chart/reloader/README.md' - -jobs: - qa: - uses: stakater/.github/.github/workflows/pull_request_doc_qa.yaml@v0.0.163 - with: - MD_CONFIG: .github/md_config.json - DOC_SRC: docs - MD_LINT_CONFIG: .markdownlint.yaml - build: - uses: stakater/.github/.github/workflows/pull_request_container_build.yaml@v0.0.163 - with: - DOCKER_FILE_PATH: Dockerfile-docs - CONTAINER_REGISTRY_URL: ghcr.io/stakater - PUSH_IMAGE: false - secrets: - CONTAINER_REGISTRY_USERNAME: ${{ github.actor }} - CONTAINER_REGISTRY_PASSWORD: ${{ secrets.GHCR_TOKEN }} - SLACK_WEBHOOK_URL: ${{ secrets.STAKATER_DELIVERY_SLACK_WEBHOOK }} diff --git a/.github/workflows/push-pr-image.yaml b/.github/workflows/push-pr-image.yaml index eff22f7..9d8681c 100644 --- a/.github/workflows/push-pr-image.yaml +++ b/.github/workflows/push-pr-image.yaml @@ -8,11 +8,6 @@ on: paths: - '!.markdownlint.yaml' - '!.vale.ini' - - '!Dockerfile-docs' - - '!docs-nginx.conf' - - '!docs/**' - - '!theme_common' - - '!theme_override' - '!deployments/kubernetes/chart/reloader/**' env: diff --git a/.github/workflows/push.yaml b/.github/workflows/push.yaml index 6340f0f..b7908bf 100644 --- a/.github/workflows/push.yaml +++ b/.github/workflows/push.yaml @@ -186,37 +186,6 @@ jobs: org.opencontainers.image.source=${{ github.event.repository.clone_url }} org.opencontainers.image.revision=${{ github.sha }} - - uses: dorny/paths-filter@v3 - id: filter - with: - filters: | - docs: - - '.markdownlint.yaml' - - '.vale.ini' - - 'Dockerfile-docs' - - 'docs-nginx.conf' - - 'docs/**' - - 'README.md' - - 'theme_common' - - 'theme_override' - - # run only if 'docs' files were changed - - name: Build and Push Docker Image for Docs to ghcr registry - if: steps.filter.outputs.docs == 'true' - uses: docker/build-push-action@v6 - with: - context: . - file: Dockerfile-docs - pull: true - push: true - build-args: BUILD_PARAMETERS=${{ env.BUILD_PARAMETERS }} - cache-to: type=inline - tags: | - ${{ env.GHCR_IMAGE_REPOSITORY }}/docs:merge-${{ github.event.number }} - labels: | - org.opencontainers.image.source=${{ github.event.repository.clone_url }} - org.opencontainers.image.revision=${{ github.sha }} - - name: Push Latest Tag uses: anothrNick/github-tag-action@1.75.0 env: diff --git a/.github/workflows/release.yaml b/.github/workflows/release.yaml index 32cecd6..fac3fe7 100644 --- a/.github/workflows/release.yaml +++ b/.github/workflows/release.yaml @@ -186,21 +186,6 @@ jobs: org.opencontainers.image.created=${{ steps.prep.outputs.created }} org.opencontainers.image.revision=${{ github.sha }} - - name: Build and Push Docker Image for Docs to ghcr registry - uses: docker/build-push-action@v6 - with: - context: . - file: Dockerfile-docs - pull: true - push: true - cache-to: type=inline - tags: | - ${{ env.GHCR_IMAGE_REPOSITORY }}/docs:${{ steps.generate_tag.outputs.RELEASE_VERSION }} - labels: | - org.opencontainers.image.source=${{ github.event.repository.clone_url }} - org.opencontainers.image.created=${{ steps.prep.outputs.created }} - org.opencontainers.image.revision=${{ github.sha }} - ############################## ## Add steps to generate required artifacts for a release here(helm chart, operator manifest etc.) ############################## diff --git a/Dockerfile-docs b/Dockerfile-docs deleted file mode 100644 index feb745c..0000000 --- a/Dockerfile-docs +++ /dev/null @@ -1,35 +0,0 @@ -FROM python:3.14-alpine as builder - -# set workdir -RUN mkdir -p $HOME/application -WORKDIR $HOME/application - -# copy the entire application -COPY --chown=1001:root . . - -RUN pip3 install -r theme_common/requirements.txt - -# Combine Theme Resources -RUN python theme_common/scripts/combine_theme_resources.py -s theme_common/resources -ov theme_override/resources -o dist/_theme -# Produce mkdocs file -RUN python theme_common/scripts/combine_mkdocs_config_yaml.py theme_common/mkdocs.yml theme_override/mkdocs.yml mkdocs.yml - -# build the docs -RUN mkdocs build - -FROM nginxinc/nginx-unprivileged:1.29-alpine as deploy -COPY --from=builder $HOME/application/site/ /usr/share/nginx/html/reloader/ -COPY docs-nginx.conf /etc/nginx/conf.d/default.conf - -# set non-root user -USER 1001 - -LABEL name="Stakater Reloader Documentation" \ - maintainer="Stakater " \ - vendor="Stakater" \ - release="1" \ - summary="Documentation for Stakater Reloader" - -EXPOSE 8080:8080/tcp - -CMD ["nginx", "-g", "daemon off;"] diff --git a/README.md b/README.md index 23d11cb..c7bda71 100644 --- a/README.md +++ b/README.md @@ -19,6 +19,8 @@ In a traditional Kubernetes setup, updating a `Secret` or `ConfigMap` does not a Reloader bridges that gap by ensuring your workloads stay in sync with configuration changes — automatically and safely. +📚 Full documentation is available at [Stakater documentation site](https://docs.stakater.com/reloader/) + ## 🚀 Why Reloader? - ✅ **Zero manual restarts**: No need to manually rollout workloads after config/secret changes. @@ -465,10 +467,6 @@ If you're running Reloader in production, we'd love to hear from you: ## Help -### Documentation - -The Reloader documentation can be viewed from [the doc site](https://docs.stakater.com/reloader/). The doc source is in the [docs](./docs/) folder. - ### Have a question? File a GitHub [issue](https://github.com/stakater/Reloader/issues). diff --git a/docs-nginx.conf b/docs-nginx.conf deleted file mode 100644 index f389714..0000000 --- a/docs-nginx.conf +++ /dev/null @@ -1,11 +0,0 @@ -server { - listen 8080; - root /usr/share/nginx/html/; - index index.html; - error_page 403 404 /404.html; - location = /404.html { - internal; - } - # redirects issued by nginx will be relative - absolute_redirect off; -} diff --git a/docs/Alerting.md b/docs/Alerting.md deleted file mode 100644 index bb4fbbe..0000000 --- a/docs/Alerting.md +++ /dev/null @@ -1,18 +0,0 @@ -# Alerting on Reload - -Reloader can alert when it triggers a rolling upgrade on Deployments or StatefulSets. Webhook notification alert would be sent to the configured webhook server with all the required information. - -## Enabling - -In-order to enable this feature, you need to update the `reloader.env.secret` section of `values.yaml` providing the information needed for alert: - -```yaml - ALERT_ON_RELOAD: [ true/false ] Default: false - ALERT_SINK: [ slack/teams/gchat/webhook ] Default: webhook - ALERT_WEBHOOK_URL: Required if ALERT_ON_RELOAD is true - ALERT_ADDITIONAL_INFO: Any additional information to be added to alert -``` - -## Slack Incoming-Webhook Creation Docs - -[Sending messages using Incoming Webhooks](https://api.slack.com/messaging/webhooks) diff --git a/docs/Container Build.md b/docs/Container Build.md deleted file mode 100644 index d48d438..0000000 --- a/docs/Container Build.md +++ /dev/null @@ -1,53 +0,0 @@ -# Container Build - -> **WARNING:** As a user of Reloader there is no need to build containers, the open source version is available on [Docker Hub](https://hub.docker.com/r/stakater/reloader/). - -Multi-architecture approach is based on original work by [@mdh02038](https://github.com/mdh02038/Reloader). - -Images are tested on linux/arm, linux/arm64 and linux/amd64. - -## Install Pre-Reqs - -The build environment requires the following packages (tested on `Ubuntu 20.04`): - -* Golang -* `make` -* `qemu` (for arm, arm64 etc. emulation) -* binfmt-support -* Docker engine - -## Docker - -Follow instructions on [Install using the apt repository](https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository). - -Once installed, enable the experimental CLI: - -```bash -export DOCKER_CLI_EXPERIMENTAL=enabled -``` - -Login to enable publishing of packages: - -```bash -sudo docker login -``` - -## Remaining Pre-Reqs - -Remaining Pre-Reqs can be installed via: - -```bash -sudo apt install golang make qemu-user-static binfmt-support -y -``` - -## Publish Multi-Architecture Image - -To build/ publish multi-arch Docker images clone repository and execute from repository root: - -```bash -sudo make release-all -``` - -## Additional Links/Info - -[Building Multi-Architecture Docker Images With `Buildx`](https://medium.com/@artur.klauser/building-multi-architecture-docker-images-with-buildx-27d80f7e2408) diff --git a/docs/Helm2-to-Helm3.md b/docs/Helm2-to-Helm3.md deleted file mode 100644 index c55eae1..0000000 --- a/docs/Helm2-to-Helm3.md +++ /dev/null @@ -1,68 +0,0 @@ -# Helm2 to Helm3 Migration - -Follow below-mentioned instructions to migrate Reloader from Helm2 to Helm3 - -## Instructions - -There are 3 steps involved in migrating the Reloader from Helm2 to Helm3. - -### Step 1 - -Install the `helm-2to3` plugin - -```bash -helm3 plugin install https://github.com/helm/helm-2to3 - -helm3 2to3 convert - -helm3 2to3 cleanup --release-cleanup --skip-confirmation -``` - -### Step 2 - -Add the following Helm3 labels and annotations on Reloader resources. - -Label: - -```yaml -app.kubernetes.io/managed-by=Helm -``` - -Annotations: - -```yaml -meta.helm.sh/release-name= -meta.helm.sh/release-namespace= -``` - -For example, to label and annotate the ClusterRoleBinding and ClusterRole: - -```bash -KIND=ClusterRoleBinding -NAME=reloader-reloader-role-binding -RELEASE=reloader -NAMESPACE=kube-system -kubectl annotate $KIND $NAME meta.helm.sh/release-name=$RELEASE -kubectl annotate $KIND $NAME meta.helm.sh/release-namespace=$NAMESPACE -kubectl label $KIND $NAME app.kubernetes.io/managed-by=Helm - -KIND=ClusterRole -NAME=reloader-reloader-role -RELEASE=reloader -NAMESPACE=kube-system -kubectl annotate $KIND $NAME meta.helm.sh/release-name=$RELEASE -kubectl annotate $KIND $NAME meta.helm.sh/release-namespace=$NAMESPACE -kubectl label $KIND $NAME app.kubernetes.io/managed-by=Helm -``` - -### Step 3 - -Upgrade to desired version - -```bash -helm3 repo add stakater https://stakater.github.io/stakater-charts - -helm3 repo update - -helm3 upgrade stakater/reloader --version=v0.0.72 -``` diff --git a/docs/How-it-works.md b/docs/How-it-works.md deleted file mode 100644 index c0ae964..0000000 --- a/docs/How-it-works.md +++ /dev/null @@ -1,93 +0,0 @@ -# How Does Reloader Work? - -Reloader watches for `ConfigMap` and `Secret` and detects if there are changes in data of these objects. After change detection Reloader performs rolling upgrade on relevant Pods via associated `Deployment`, `Daemonset` and `Statefulset`: - -```mermaid -flowchart LR - subgraph Reloader - controller("Controller watches in a loop") -- "Detects a change" --> upgrade_handler("Upgrade handler checks if the change is a valid data change by comparing the change hash") - upgrade_handler -- "Update resource" --> update_resource("Updates the resource with computed hash of change") - end - Reloader -- "Watches" --> secret_configmaps("Secrets/ConfigMaps") - Reloader -- "Updates resources with Reloader environment variable" --> resources("Deployments/DaemonSets/StatefulSets resources with Reloader annotation") - resources -- "Restart pods based on StrategyType" --> Pods -``` - -## How Does Change Detection Work? - -Reloader watches changes in `ConfigMaps` and `Secrets` data. As soon as it detects a change in these. It forwards these objects to an update handler which decides if and how to perform the rolling upgrade. - -## Requirements for Rolling Upgrade - -To perform rolling upgrade a `deployment`, `daemonset` or `statefulset` must have - -- support for rolling upgrade strategy -- specific annotation for `ConfigMaps` or `Secrets` - -The annotation value is comma separated list of `ConfigMaps` or `Secrets`. If a change is detected in data of these `ConfigMaps` or `Secrets`, Reloader will perform rolling upgrades on their associated `deployments`, `daemonsets` or `statefulsets`. - -### Annotation for ConfigMap - -For a `Deployment` called `foo` have a `ConfigMap` called `foo`. Then add this annotation* to your `Deployment`, where the default annotation can be changed with the `--configmap-annotation` flag: - -```yaml -metadata: - annotations: - configmap.reloader.stakater.com/reload: "foo" -``` - -### Annotation for Secret - -For a `Deployment` called `foo` have a `Secret` called `foo`. Then add this annotation to your `Deployment`, where the default annotation can be changed with the `--secret-annotation` flag: - -```yaml -metadata: - annotations: - secret.reloader.stakater.com/reload: "foo" -``` - -Above mentioned annotation are also work for `Daemonsets` `Statefulsets` and `Rollouts` - -## How Does Rolling Upgrade Work? - -When Reloader detects changes in `ConfigMap`. It gets two objects of `ConfigMap`. First object is an old `ConfigMap` object which has a state before the latest change. Second object is new `ConfigMap` object which contains latest changes. Reloader compares both objects and see whether any change in data occurred or not. If Reloader finds any change in new `ConfigMap` object, only then, it moves forward with rolling upgrade. - -After that, Reloader gets the list of all `deployments`, `daemonsets` and `statefulset` and looks for above mentioned annotation for `ConfigMap`. If the annotation value contains the `ConfigMap` name, it then looks for an environment variable which can contain the `ConfigMap` or secret data change hash. - -### Environment Variable for ConfigMap - -If `ConfigMap` name is foo then - -```yaml -STAKATER_FOO_CONFIGMAP -``` - -### Environment Variable for Secret - -If Secret name is foo then - -```yaml -STAKATER_FOO_SECRET -``` - -If the environment variable is found then it gets its value and compares it with new `ConfigMap` hash value. If old value in environment variable is different from new hash value then Reloader updates the environment variable. If the environment variable does not exist then it creates a new environment variable with latest hash value from `ConfigMap` and updates the relevant `deployment`, `daemonset` or `statefulset` - -Note: Rolling upgrade also works in the same way for secrets. - -### Hash Value Computation - -Reloader uses SHA1 to compute hash value. SHA1 is used because it is efficient and less prone to collision. - -## Monitor All Namespaces - -By default Reloader deploys in default namespace and monitors changes in all namespaces. To monitor changes in a specific namespace deploy the Reloader in that namespace and set the `watchGlobally` flag to `false` in values file located under `deployments/kubernetes/chart/reloader` and render manifest file using helm command: - -```bash -helm --namespace {replace this with namespace name} template . > reloader.yaml -``` - -The output file can then be used to deploy Reloader in specific namespace. - -## Compatibility With Helm Install and Upgrade - -Reloader has no impact on helm deployment cycle. Reloader only injects an environment variable in `deployment`, `daemonset` or `statefulset`. The environment variable contains the SHA1 value of `ConfigMaps` or `Secrets` data. So if a deployment is created using Helm and Reloader updates the deployment, then next time you upgrade the helm release, Reloader will do nothing except changing that environment variable value in `deployment` , `daemonset` or `statefulset`. diff --git a/docs/Reloader-vs-ConfigmapController.md b/docs/Reloader-vs-ConfigmapController.md deleted file mode 100644 index 1433daa..0000000 --- a/docs/Reloader-vs-ConfigmapController.md +++ /dev/null @@ -1,11 +0,0 @@ -# Reloader vs ConfigmapController - -Reloader is inspired from [`configmapcontroller`](https://github.com/fabric8io/configmapcontroller) but there are many ways in which it differs from `configmapcontroller`. Below is the small comparison between these two controllers. - -| Reloader | ConfigMap | -|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Reloader can watch both `Secrets` and `ConfigMaps`. | `configmapcontroller` can only watch changes in `ConfigMaps`. It cannot detect changes in other resources like `Secrets`. | -| Reloader can perform rolling upgrades on `deployments` as well as on `statefulsets` and `daemonsets` | `configmapcontroller` can only perform rolling upgrades on `deployments`. It currently does not support rolling upgrades on `statefulsets` and `daemonsets` | -| Reloader provides both unit test cases and end to end integration test cases for future updates. So one can make sure that new changes do not break any old functionality. | Currently there are not any unit test cases or end to end integration test cases in `configmap-controller`. It adds difficulties for any additional updates in `configmap-controller` and one can not know for sure whether new changes breaks any old functionality or not. | -| Reloader uses SHA1 to encode the change in `ConfigMap` or `Secret`. It then saves the SHA1 value in `STAKATER_FOO_CONFIGMAP` or `STAKATER_FOO_SECRET` environment variable depending upon where the change has happened. The use of SHA1 provides a concise 40 characters encoded value that is very less prone to collision. | `configmap-controller` uses `FABRICB_FOO_REVISION` environment variable to store any change in `ConfigMap` controller. It does not encode it or convert it in suitable hash value to avoid data pollution in deployment. | -| Reloader allows you to customize your own annotation (for both `Secrets` and `ConfigMaps`) using command line flags | `configmap-controller` restricts you to only their provided annotation | diff --git a/docs/Reloader-vs-k8s-trigger-controller.md b/docs/Reloader-vs-k8s-trigger-controller.md deleted file mode 100644 index 561dca5..0000000 --- a/docs/Reloader-vs-k8s-trigger-controller.md +++ /dev/null @@ -1,46 +0,0 @@ -# Reloader vs k8s-trigger-controller - -Reloader and k8s-trigger-controller are both built for same purpose. So there are quite a few similarities and differences between these. - -## Similarities - -- Both controllers support change detection in `ConfigMaps` and `Secrets` -- Both controllers support deployment `rollout` -- Reloader controller use SHA1 for hashing -- Both controllers have end to end as well as unit test cases. - -## Differences - -### Support for `Daemonsets` and `Statefulsets` - -#### `k8s-trigger-controller` - -`k8s-trigger-controller` only support for deployment `rollout`. It does not support `daemonsets` and `statefulsets` `rollout`. - -#### Reloader - -Reloader supports deployment `rollout` as well as `daemonsets` and `statefulsets` `rollout`. - -### Hashing Usage - -#### `k8s-trigger-controller` - -`k8s-trigger-controller` stores the hash value in an annotation `trigger.k8s.io/[secret|configMap]-NAME-last-hash` - -#### Reloader - -Reloader stores the hash value in an environment variable `STAKATER_NAME_[SECRET|CONFIGMAP]` - -### Customization - -#### `k8s-trigger-controller` - -`k8s-trigger-controller` restricts you to using the `trigger.k8s.io/[secret-configMap]-NAME-last-hash` annotation - -#### Reloader - -Reloader allows you to customize the annotation to fit your needs with command line flags: - -- `--auto-annotation ` -- `--configmap-annotation ` -- `--secret-annotation ` diff --git a/docs/Reloader-with-Sealed-Secrets.md b/docs/Reloader-with-Sealed-Secrets.md deleted file mode 100644 index 4df328d..0000000 --- a/docs/Reloader-with-Sealed-Secrets.md +++ /dev/null @@ -1,14 +0,0 @@ -# Using Reloader with Sealed Secrets - -Below are the steps to use Reloader with Sealed Secrets: - -1. Download and install the kubeseal client from [here](https://github.com/bitnami-labs/sealed-secrets) -1. Install the controller for Sealed Secrets -1. Fetch the encryption certificate -1. Encrypt the secret -1. Apply the secret -1. Install the tool which uses that Sealed Secret -1. Install Reloader -1. Once everything is setup, update the original secret at client and encrypt it with kubeseal to see Reloader working -1. Apply the updated Sealed Secret -1. Reloader will restart the pod to use that updated secret diff --git a/docs/Verify-Reloader-Working.md b/docs/Verify-Reloader-Working.md deleted file mode 100644 index 1e9146f..0000000 --- a/docs/Verify-Reloader-Working.md +++ /dev/null @@ -1,75 +0,0 @@ -# Verify Reloader's Working - -Reloader's working can be verified by three ways. - -## Verify From Logs - -Check the logs of Reloader and verify that you can see logs looks like below, if you are able to find these logs then it means Reloader is working. - -```text -Changes Detected in test-object of type 'SECRET' in namespace: test-reloader - -Updated test-resource of type Deployment in namespace: test-reloader -``` - -Below are the details that explain these logs: - -### `test-object` - -`test-object` is the name of a `secret` or a `configmap` in which change has been detected. - -### `SECRET` - -`SECRET` is the type of `test-object`. It can either be `SECRET` or `CONFIGMAP` - -### `test-reloader` - -`test-reloader` is the name of namespace in which Reloader has detected the change. - -### `test-resource` - -`test-resource` is the name of resource which is going to be updated - -### `Deployment` - -`Deployment` is the type of `test-resource`. It can either be a `Deployment`, `Daemonset` or `Statefulset` - -## Verify by Checking the Age of Pod - -A pod's age can tell whether Reloader is working correctly or not. If you know that a change in a `secret` or `configmap` has occurred, then check the relevant Pod's age immediately. It should be newly created few moments ago. - -### Verify from Kubernetes Dashboard - -`kubernetes dashboard` can be used to verify the working of Reloader. After a change in `secret` or `configmap`, check the relevant Pod's age from dashboard. It should be newly created few moments ago. - -### Verify from Command Line - -After a change in `secret` or `configmap`. Run the below-mentioned command and verify that the pod is newly created. - -```bash -kubectl get pods -n -``` - -## Verify From Metrics - -Some metrics are exported to Prometheus endpoint `/metrics` on port `9090`. - -When Reloader is unable to reload, `reloader_reload_executed_total{success="false"}` metric gets incremented and when it reloads successfully, `reloader_reload_executed_total{success="true"}` gets incremented. You will be able to see the following metrics, with some other metrics, at `/metrics` endpoint. - -```text -reloader_reload_executed_total{success="false"} 15 -reloader_reload_executed_total{success="true"} 12 -``` - -### Reloads by Namespace - -Reloader can also export a metric to show the number of reloads by namespace. This feature is disabled by default, as it can lead to high cardinality in clusters with many namespaces. - -The metric will have both `success` and `namespace` as attributes: - -```text -reloader_reload_executed_total{success="false", namespace="some-namespace"} 2 -reloader_reload_executed_total{success="true", namespace="some-namespace"} 1 -``` - -To opt in, set the environment variable `METRICS_COUNT_BY_NAMESPACE` to `enabled` or set the Helm value `reloader.enableMetricsByNamespace` to `true`. diff --git a/docs/index.md b/docs/index.md deleted file mode 100644 index 1197186..0000000 --- a/docs/index.md +++ /dev/null @@ -1,26 +0,0 @@ -# Introduction - -Reloader can watch changes in `ConfigMap` and `Secret` and do rolling upgrades on Pods with their associated `DeploymentConfigs`, `Deployments`, `Daemonsets` `Statefulsets` and `Rollouts`. - -These are the key features of Reloader: - -1. Restart pod in a `deployment` on change in linked/related `ConfigMaps` or `Secrets` -1. Restart pod in a `daemonset` on change in linked/related `ConfigMaps` or `Secrets` -1. Restart pod in a `statefulset` on change in linked/related `ConfigMaps` or `Secrets` -1. Restart pod in a `rollout` on change in linked/related `ConfigMaps` or `Secrets` - -This site contains more details on how Reloader works. For an overview, please see the repository's [README file](https://github.com/stakater/Reloader/blob/master/README.md). - ---- - -
- -[![💖 Sponsor our work](https://img.shields.io/badge/Sponsor%20Our%20Work-FF8C00?style=for-the-badge&logo=github-sponsors&logoColor=white)](https://github.com/sponsors/stakater?utm_source=docs&utm_medium=footer&utm_campaign=reloader) - -

-Your support funds maintenance, security updates, and new features for Reloader, plus continued investment in other open source tools. -

- -
- ---- diff --git a/theme_common b/theme_common deleted file mode 160000 index 11286e1..0000000 --- a/theme_common +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 11286e112ea55c995232ea415038456ab3f70f59 diff --git a/theme_override/mkdocs.yml b/theme_override/mkdocs.yml deleted file mode 100644 index 265ec60..0000000 --- a/theme_override/mkdocs.yml +++ /dev/null @@ -1,22 +0,0 @@ -site_name: Stakater Reloader -docs_dir: docs -site_url: https://docs.stakater.com/reloader/ -repo_url: https://github.com/stakater/reloader -edit_uri: blob/master/docs/ - -theme: - favicon: assets/images/favicon.svg - -nav: - - index.md - - How-to Guides: - - Verify-Reloader-Working.md - - Alerting.md - - Reloader-with-Sealed-Secrets.md - - Helm2-to-Helm3.md - - References: - - How-it-works.md - - Container Build.md - - Comparisons with similar tools: - - Reloader-vs-ConfigmapController.md - - Reloader-vs-k8s-trigger-controller.md diff --git a/theme_override/resources/.gitignore b/theme_override/resources/.gitignore deleted file mode 100644 index e69de29..0000000 diff --git a/theme_override/resources/assets/images/favicon.svg b/theme_override/resources/assets/images/favicon.svg deleted file mode 100644 index c353305..0000000 --- a/theme_override/resources/assets/images/favicon.svg +++ /dev/null @@ -1 +0,0 @@ - \ No newline at end of file