Dexly

Cryptocurrency trading bot.

Table of Contents

• Cloud infrastructure
  • Prerequisites
  • Create infrastructure components
  • Destroy infrastructure components
• Continuous integration
• Continuous deployment

Cloud infrastructure

This project contains the configuration of Google Cloud Platform infrastructure needed to run all components in a seamless way.

Prerequisites

To configure the infrastructure on GCP, you will need to:

1. Configure your account and project.

2. Create a service account for Terraform. For simplicity, give it the project’s owner role and generate an account key. Download the account key and keep it safe, somewhere on your local machine.

3. Install Terraform (at least 0.15.1) on your local machine.

Create infrastructure components

First, set the GOOGLE_CREDENTIALS environment variable to point to your service account key path, by doing:

export GOOGLE_CREDENTIALS=<service-account-key>

Then, you need to perform an one-off initialization of the remote state bucket. Move to the infrastructure/terraform/remote-state directory and invoke:

terraform init && terraform apply

A Google Cloud bucket will be created. Terraform will use it to store its state. You can now start creating all cloud resources by moving to the infrastructure/terraform directory and invoking:

terraform init && terraform apply

Once the process terminates, all cloud resources should be up and running. Please note the outputs as they may be needed in further steps.

Destroy infrastructure components

You can quickly destroy all cloud resources by doing:

terraform destroy

Remember about setting the service account key path via the GOOGLE_CREDENTIALS variable.

Continuous integration

This project uses GitHub Actions as continuous integration runner. Each service contains its workflow definition defined in the .github/workflows directory.

Each workflow consists of several jobs:

• build which builds the microservice code. This job is performed on all pushes and pull requests.

• test which performs unit and integration tests. This job is performed on all pushes and pull requests.

• publish which builds the Docker image and publishes it to the registry. This job is performed only on pushes to the master branch. It also updates the image digest in the Kubernetes manifest and commits that change.

The above jobs need several secrets to be defined in the repository settings:

• DOCKER_REGISTRY_URL which should point to the registry URL.

• DOCKER_REPOSITORY_ID which should contain the image repository name.

• DOCKER_REGISTRY_KEY which should contain the registry key in JSON format.

Continuous deployment

Regarding continuous deployment, several crucial components are configured as part of the infrastructure described in Cloud infrastructure section. Those components are:

• GCR which serves as target repository for images built during the publish job described in Continuous integration section.

• GKE cluster used as environment for containerized services.

• ArgoCD which is a GitOps delivery tool for Kubernetes

Those parts work together to continuously deploy services as soon as new code lands on master. Everything starts once the publish job pushes the new image to GCR and commits the image digest change made in the service manifest. ArgoCD observes the cluster state and compares it against the source Git repository, as defined in the infrastructure/helm/argo-applications chart. In case of divergence (e.g. new image digest is used), ArgoCD makes efforts to move the cluster to the desired state. This way microservices are deployed in a fully-automated and continuous way.