I confess, I never did complete migrating my software’s website from a Ruby on Rails app with an embedded local mySQL database running on a VM in the cloud to a full cloud native application leveraging lots of AWS goodness. I got as far as putting the installer binaries in an S3 bucket and referencing them from the app. And I only did that as the repo had become greater than the max size allowed by BitBucket. I then studied all the different options, my real job took me to focussing on cloud native applications and I could see I was barking up yesterdays tree. The set up I’m running today is the day before yesterdays tree. Cloud Native all the way is the future.
From the earlier studies I could see it’s a big job migrating something that “just works”, has a complete deployment automation to UAT and production sites, courtesy of capistrano to a new world order while maintaining the simplicity of deployment enjoyed today. I recall that didn’t come easy, SSL certs, schema refreshes, Facebook integration for Oauth and so on. Rome wasn’t built in a day and neither will the next gen Drum Score Editor website be.
The first thing is to get to a point where development iterations can be fast, simple and automated. That’s because the scope of the app in terms of functions is too broad for a big bang approach so we’ll be developing in bite size chunks. When you do that you don’t want a massive overhead in testing, packaging and deploying your app, and in cloud native speak that means we need a Continuous Integration / Continuous Deployment pipeline. First investment should be in getting that up and running to be as efficient and agile as possible in getting new updates out. Eclipse is my IDE of choice so to be able to commit and push an update resulting in the changes pushed to the CDN’s caching the edge of the web would be ideal!
To build and prove the CI / CD pipeline, we’re starting with a static site containing the documentation pages, hosted on S3, developed using Eclipse, hosted in GitHub, deployed automatically to a UAT site using Travis. Why Travis, why GitHub, why S3 – because it’s a pattern that appears to be quite mature, so help is at hand courtesy of the usual places that Mr Google serves up, stackoverlow, personal blogs etc.
Travis uses your GitHub account, so integration was relatively easy, it found all my repos there although a slight hiccup in that it just sat there at the first_sync page and left me wondering but given I hadn’t read a single line of documentation at this stage I considered it so far so good! Activated the repo I needed in my Travis profile then set about setting up the static site on AWS.
Plenty of good how-to pages out there on setting up a static site. Wishing to use Zurb Foundation as the front-end framework, I downloaded their distro to a new static web project in Eclipse and followed the AWS docs to set up the static website in S3. Next was to enable a CloudFront distribution and then looked at putting a cert on the front. At this point I found my cert provider had been removed from the good guys club and all my certs would no longer be trusted. Thanks Startcom, or more accurately WoSign for your failures including not disclosing the acquisition of Startcom. Leaving it as http://docs.drumscore.scot for now, will revisit certificate renewal and reissue hell across my stuff at a later date. Depending on when you try that link you’ll either get the Foundation intro page or more of my docs as this develops!
Next is to get Travis talking to AWS, I followed Renzo Lucioni’s how-to, to set up the credentials Travis needs on AWS to update the S3 bucket and invalidate the CloudFront distribution, so it picks up the changes and pushes them to the edge. Watch that although the blog sets the environment variable for the AWS default region, it doesn’t include it in the s3 upload params, see the Travis S3 Deployment page. I’ve contacted Renzo, i.e. raised an issue as his blog is a static website generated from GitHub – great toolchain!
One thing to note, Eclipse insists on creating a folder with your project name in then another under that called WebContent. The .travis.yml file must go in the root of the git repo. Renzo’s example calls for the files to be deployed to reside in a folder called ‘build’ in the root of the Travis build container. I didn’t like the idea of an empty build script as I will be putting more in there soon, so add a line to create the build directory, and another to copy the contents of the static site there.
language: python python: - "3.5" cache: pip install: # Install any dependencies required for building your site here. # `awscli` is required for invalidation of CloudFront distributions. - pip install awscli script: # Build your site (e.g., HTML, CSS, JS) here. - mkdir build - cp -Rp DocNext/WebContent/* build deploy: # Control deployment by setting a value for `on`. Setting the `branch` # option to `master` means Travis will only attempt a deployment on # builds of your repo's master branch (e.g., after you merge a PR). on: branch: master provider: s3 # You can refer to environment variables from Travis repo settings! access_key_id: $AWS_ACCESS_KEY_ID secret_access_key: $AWS_SECRET_ACCESS_KEY region: $AWS_DEFAULT_REGION # Name of the S3 bucket to which your site should be uploaded. bucket: docs.drumscore.scot # Prevent Travis from deleting your built site so it can be uploaded. skip_cleanup: true # Path to a directory containing your built site. local_dir: build # Set the Cache-Control header. cache_control: "max-age=21600" after_deploy: # Allow `awscli` to make requests to CloudFront. - aws configure set preview.cloudfront true # Invalidate every object in the targeted distribution. - aws cloudfront create-invalidation --distribution-id $CLOUDFRONT_DISTRIBUTION_ID --paths "/*"
So here’s the summary:
- Create a new Eclipse static website project and populate with the Zurb Foundation download, turn into a git repo, create GitHub repo, commit and push.
- Create your S3 buckets, CloudFront distribution, DNS entry
- Create your Travis account linked to your GitHub
- Copy in the .travis.yml file from Renzo’s blog, add the tweaks to populate the build directory and fix the region setting
- Commit and push to GitHub, watch the magic happen in Travis