Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change insecure links #11

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,13 +31,12 @@ This will automatically run migrations on all future deployment changes.

### API

There's one API object, the [Migrator](https://github.com/coderanger/migrations-operator/blob/main/api/v1beta1/migrator_types.go),
with these fields:
There's one API object, the [Migrator][migrator-src], with these fields:

- selector: [LabelSelector](https://v1-18.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#labelselector-v1-meta)
- selector: [LabelSelector][k8s-labelselector]
for which pods to watch to trigger an upgrade action.
- templateSelector: optional
[LabelSelector](https://v1-18.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#labelselector-v1-meta) for which
[LabelSelector][k8s-labelselector]
specific pod, selected by `selector`, to use as a template for building the upgrade Job.
- command: optional string array which will be used as the upgrade Job's `command`.
- args: optional string array to be used as the upgrade Job's `args`.
Expand All @@ -62,3 +61,7 @@ A common choice for running database migrations is the `pre-install/upgrade` hoo
### Migrations-Operator vs. Init Container

Another common solution for database migrations is an init container to run the migration commands. The main problem here is locking, if you run 4 replicas of your application, all 4 of those are going to try and apply your migrations in parallel. You could add some leader election code to your migrations runner, however this has to be built in at the application image level and so requires a specific solution for each application framework or toolkit. Migrations-Operator has a top-level view of the world and so can ensure for only a single job at a time is created.


[k8s-labelselector]: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
[migrator-src]: https://github.com/coderanger/migrations-operator/blob/main/api/v1beta1/migrator_types.go