With Google rapidly expanding their cloud service coverage, Buddy keeps up the pace with dedicated integrations for Google developers.
Table of contents:
Deploy to GCS (Google Cloud Storage)
Google Cloud Storage is a unified object storage service for developers and enterprises. It offers four types of storage: Multi-regional, ideal for frequently accessed website assets like videos; Regional, ideal for cloud developers because of its availability and performance; and Nearline/Coldline storages for rarely accessed data.
Deploy to GCE (Google Compute Engine)
Google Compute Engine – an equivalent of AWS EC2 – is a virtual machine in Google Cloud that you can connect to via SFTP and use to serve your application.
The project is Java/Maven. The application in the form of a
.war file is uploaded to the GCE and restarted with an SSH script on every push to the repository:
Deploy to GAE (Google App Engine)
Google App Engine lets developers upload, build and serve web and mobile backends on Google's infrastructure. The service is similar to Heroku or Amazon's Elastic Beanstalk.
With Buddy, you can automate deployments to GAE using a dedicated file transfer action. Just like in previous actions, you can upload your package automatically on push to the selected branch or a wildcard pattern, on demand, or recurrently at a specific time.
Build and push Docker image to GCR (Google Container Registry)
To build a Docker image, you need a repository with the application code and a dockerfile with instructions how the image should be built. You can configure Buddy to build a new Docker image and push it to the GCR on every push to the selected branch. It's also possible to add an SSH action that will pull the Docker image on the selected host and launch the new version of the application.
You can read more about building Docker images in this article.
Automate delivery to GKE (Google Container Enginge)
Google Container Engine is a cluster manager and orchestration system run in Google Cloud. It is based on Kubernetes open source container management system and is most often used by software developers for creating enterprise applications that require scalability and performance.
Buddy has 4 dedicated actions, that help you automate your delivery process for GKE:
- Apply deployment
- Set image
- Run Job
- Run Pod
In GKE your application is defined with the deployment objective that you describe in the YAML file. In this file you decide which image will be run and how the update proccess should look like. If you want to update your app, you just need to make changes in this YAML file and perform Apply deployment in your cluster.
This action allows you to automaticaly apply the changes based on the config file in the repo.
After every push to the Master branch, Buddy will test your application, apply deployment to GKE, and send a notification to your team:
GKE also allows you to update the Docker image version in your application in another way. Instead of performing 'apply' on the whole deployment objective, you can execute Set image operation in the cluster, in which you set the version of the image for every deployment.
In Buddy, the action will automaticaly set the image in deployment right after you build a new image for your app.
Buddy builds an image after every change to the Dockerfile in your repo. It pushes the new image to the GCR, then runs the Set image action which activates the newly built image in your deployment.
Run pod / Run job
To perform operations such us backups or db migrations in GKE you can run a pod or a job. The difference between Run pod and Run job is that the first one performs the indicated action and ends either as successful or failed, while the second oneruns a series of pods until a specified amount of them ends as successful (you can set the amount in the job configuration).
Buddy lets you add this process to your delivery pipeline with just a few clicks. All you need to do is select the YAML file that defines that job/pod.
After every push to the repository:
- Buddy builds a new image and pushes it to the GCR
- Then runs a job that will prepare a database for the new version of the application.
- Executes 'set image' that will replace the image in our deployment.