Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2018-03-26T02:07:15.787Z
Comments: 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.
Comments: Jonah Benton
Comments: CC BY-SA 3.0
Comments: 2018-03-26T04:14:14.890Z
Comments: 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.
Comments: Jonah Benton
Comments: CC BY-SA 3.0
Comments: 2018-04-02T06:00:07.493Z
Comments: 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.
Comments: WeiChing 林煒清
Comments: CC BY-SA 4.0
Comments: 2018-06-14T19:09:13.683Z
Comments: 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?
Comments: Jose Armesto
Comments: CC BY-SA 4.0
Comments: 2019-12-23T09:08:06.433Z
Comments: Could you indicate whether you solved the issue?
Comments: 030
Tags: <kubernetes>
Title: Is there a standard pattern for doing flyway migrations on a kubernetes stack?
UserDisplayName: dwjohnston
ThreadText: # 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](https://developers.redhat.com/blog/2018/01/10/flyway-containerized-db-changes/) 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'.
  
  **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
  
  