A lot of work with Flyway is going to take place on development machines with the Flyway command line installed. Another healthy chunk of the work will be on dedicated instances used for Continuous Integration (CI) or Continuous Delivery (CD), again, with the command line installed. However, what happens when you start automating more than just the build process itself. For example, let’s say that we’re using AWS CodePipelines and CodeBuild to deploy database changes as part of a CI process. What now?

Installing Flyway

When I run my AWS CodePipeline, it configures a Linux instance that I’m going to use to run the CodeBuild commands from. There’s not much special about it. It’s a build instance as defined by AWS. One approach would be to simply install Flyway as part of my build process. The steps are fairly straight forward. The buildspec.yml file would look like this:

version: 0.2

phases:
    build:
        commands:
            - wget -qO- https://repo1.maven.org/maven2/org/flywaydb/flyway-commandline/6.5.3/flyway-commandline-6.5.3-linux-x64.tar.gz | tar xvz && ln -s `pwd`/flyway-6.5.3/flyway /usr/local/bin 
            - flyway -enterprise migrate

I’m using the wget command to retrieve the Flyway command line. I’m unpacking it and putting it in the /usr/local/bin folder. From there, I just execute Flyway with migrate. I’ve got my database configured in my flyway.conf file.

This works. However, it is a little slow since I have to move Flyway over the internet to my build instance and then unpack it. There is a more sophisticated way to solve this problem.

Docker

One of the things that does come on the build instance on AWS is Docker. It just so happens that there is a Flyway Docker image. This image is maintained and up to date. Let’s put it to use in AWS. I’m going to modify my buildspec.yml file to look like this:

version: 0.2
phases:
    build:
        commands:
            - docker run --rm -v $(pwd)/sql:/flyway/sql -v $(pwd)/conf:/flyway/conf flyway/flyway -enterprise migrate

Let’s unpack that command. Obviously, we're using 'docker run' to get started in Docker. We’re only using this image temporarily, hence the --rm flag. Then, I need to map some volumes, -v. These volumes are so Flyway knows where my files are, locally within the Linux instance I'm running all this on. I’m mapping my local ‘sql’ folder to ‘/flyway/sql’ and my local ‘conf’ folder to ‘flyway/conf’. After that, I have to define the container I want, 'flyway/flyway.' Then, it’s just a question of sending in the standard commands to Flyway, same as before, in order to migrate my database.

Since I’m using the config file to manage the location and login information for my PostgreSQL database living on AWS RDS, there’s nothing else I have to do to get this deployed.

Conclusion

If you check out the documentation on the container image, there are a lot more capabilities I can take advantage of using Flyway within this Docker container. However, the key takeaway is, it’s really simple and quick to get a container up and running with Flyway. Docker containers with Flyway rapidly expands the capabilities I have available in terms of automating my database deployments.