<p>There's these <a href="https://developers.redhat.com/blog/2018/01/10/flyway-containerized-db-changes/" rel="noreferrer">instructions from redhat</a> but they're cooking their own flyway. </p>

<p>Here's what I've done: </p>

<p>I have a dockerfile that looks like this: </p>

<pre><code>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"]
</code></pre>

<p>And I build it with: </p>

<pre><code>docker build -t flyway-migrate:3 . 
</code></pre>

<p>Where <code>3</code> is the number that the flyway migration is up to. </p>

<p>I then have a kubernetes job to run this script: </p>

<pre><code>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
</code></pre>

<p>This works fine, but there's a few questions I have. </p>

<ol>
<li>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. 

<ul>
<li>Is there a way to rerun jobs? </li>
<li>Is there a way to run the kubernetes job saying 'Use this image tag'. </li>
</ul></li>
</ol>

CC BY-SA 3.0
2018-03-26T02:07:15.787Z
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
CC BY-SA 3.0
2018-03-26T04:14:14.890Z
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
CC BY-SA 3.0
2018-04-02T06:00:07.493Z
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 林煒清
CC BY-SA 4.0
2018-06-14T19:09:13.683Z
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
CC BY-SA 4.0
2019-12-23T09:08:06.433Z
Could you indicate whether you solved the issue?
030
<kubernetes>
Is there a standard pattern for doing flyway migrations on a kubernetes stack?
dwjohnston
# Is there a standard pattern for doing flyway migrations on a kubernetes stack?

(Asked by: username_0 on 2018-03-25)

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. 

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'.

**Tags:** kubernetes

> **Comments:**
> **username_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.  
> **username_1**: 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.  
> **username_2**: 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.  
> **username_3**: 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?  
> **username_4**: Could you indicate whether you solved the issue?  

---

## 0 answers

