4

There's these instructions from redhat but they're cooking their own flyway.

Here's what I've done:

I have a dockerfile that looks like this:

FROM  boxfuse/flyway
ADD ./flyway /flyway

#TODO: pass the username/password in from kubernetes
CMD ["-X", "-url=jdbc:mysql://db-service", "-schemas=myapp", "-user=root", "-password=P@ssw0rd", "migrate"]

And I build it with:

docker build -t flyway-migrate:3 . 

Where 3 is the number that the flyway migration is up to.

I then have a kubernetes job to run this script:

apiVersion: batch/v1
kind: Job
metadata:
  name: flyway-job
spec:
  template:
    metadata:
      labels:
        app: java-app
        tier: flyway
        track: stable
    spec:
      containers:
        - name: flyway
          image: "flyway-migrate:3"
          imagePullPolicy: IfNotPresent
      restartPolicy: Never

This works fine, but there's a few questions I have.

  1. Whenever increment the flyway migration number, I have to rebuild the image, and then update the job, and delete the existing job and recreate it.
    • Is there a way to rerun jobs?
    • Is there a way to run the kubernetes job saying 'Use this image tag'.
6
  • 1
    The way kubernetes jobs are designed, the best/simplest thing to do is to make a new job for each migration run. Just use the migration number in the job name. Flyway is pretty reliable but having the history may come in handy. – Jonah Benton Mar 26 '18 at 2:07
  • @JonahBenton Ok. That's not a crazy suggestion. Are you suggesting I would have a folder full of flyway-migratate-v1.yaml, flyway-migrate-v2.yaml etc? – dwjohnston Mar 26 '18 at 3:51
  • No no, no need for that. One doesn't need to run n jobs, one for each migration, to bring the database up to date. One just runs one job- an attribute of which is the migration version considered to be current state. Have one job yaml file in version control. Update it after the build of the migration artifact, to bump the name of the job, and the name of the image used in migration. Commit and test run outside prod, then run in prod. That approach preserves immutability and yields the most complete history, useful in case something unpleasant happens. – Jonah Benton Mar 26 '18 at 4:14
  • I m doing the same thing as you, except I'm using ConfigMap to populate migration sql so I can get rid of the dockerfile. However, I fallback to your approach because ConfigMap volume file structure is not compatible with flyway. – WeiChing 林煒清 Apr 2 '18 at 6:00
  • what if the migration takes really long? could you folks share some code or blog posts on how to create the kubernetes job and update it with the migration version? – Jose Armesto Jun 14 '18 at 19:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.