Thursday, 14th of Jun 2018
Monolithic Serverless Deployments
Building on the previous article about the building of the Monolithic Serverless Hybrid, we wanted to discuss how we handled deployments. We needed a CI/CD tool, and as our environment was setup with GCP it made sense to utilise their services. GCP has a service called Cloud Build which, much like other CI/CD tools, is built with Docker at its core. It makes development, testing and deploying really straight forward.
Keeping the Monolithic Serverless Hybrid platforms in sync, or in an atomic state, is important. If changes are made to the way the serverless solution transforms any of the original requests, then the monolith might need some new coding to handle the data change. If the platforms run on different versions we risk data loss or corruption.
The Monolith application is a Symfony build and has Capistrano setup for the deployment of the framework to the NGINX servers. The tool is fairly well constructed and it has built in rollback controls, making our CI/CD process much simpler. With the rollback in mind, if the serverless platform fails to deploy we can retry or rollback the Symfony deployment to the previous version. Our serverless solution was built with the Serverless Framework, which has a CLI with deployments baked in for GCP.
Deploying the serverless platform is easy, just running
serverless deploy will get the platform pushed to GCP. However, we need to deal with environment details, also known as secrets, things like the MYSQL connection details. Knowing how to handle and store these are important. We can't simply commit them to GIT, it's terrible practice. Seriously, run a search on GitHub, once they are committed, consider them compromised. So instead of committing them as plaintext, we used GCP KMS. This allows us to generate an encrypted environment file and safely committing that version to GIT
Now that our secrets are safe we're able to give Cloud Build the correct IAM permissions to decrypt the file and create an environment file for the project. When we run
serverless deploy the Serverless CLI now has access to the settings and can use them in the build and deploy process.
The Serverless Framework makes use of the Deployment Manager in GCP to provision and deploy the platform. Allowing us to take a step back and see the platform spin up! It's like magic.
Launch or Burn Workflow
We've setup the deployments to be synchronous. We deploy the Symfony application first, if that's successful we then go onto deploy the serverless platform. If that's successful then we're able to start accepting traffic again. However, if it fails to deploy we don't need to burn the servers (or lack thereof), we will simply roll back the Symfony build. The NGINX server holds the previous revisions, so a simple update to the project symlink and a restart of NGINX and we're rolled back.
The Serverless Framework does offer a built in rollback method, however it's a little slower because it needs to re-provision the services, whereas the NGINX doesn't so it's much quicker, reducing our maintenance period.
With that, we have a simple CI/CD service running which keeps our platforms in an atomic state without releasing secrets to prying eyes.
You may also like
3 minute read
Post Offices don’t need servers! Which is why they make the perfect example to explain the benefits of serverless in a practical example…
4 minute read
Serverless isn't going away and more companies are starting to use it and more providers are growing their serverless offerings. So what…