Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/lukasz-zimnoch/dexly
Playground crypto trading bot leveraging the cloud-native architecture and modern DevOps toolset.
https://github.com/lukasz-zimnoch/dexly
ci-cd cloud-native cryptocurrency devops go google-cloud-platform microservices terraform
Last synced: 6 days ago
JSON representation
Playground crypto trading bot leveraging the cloud-native architecture and modern DevOps toolset.
- Host: GitHub
- URL: https://github.com/lukasz-zimnoch/dexly
- Owner: lukasz-zimnoch
- Created: 2020-12-16T15:20:38.000Z (almost 4 years ago)
- Default Branch: master
- Last Pushed: 2021-06-29T09:33:05.000Z (over 3 years ago)
- Last Synced: 2024-06-21T19:07:22.996Z (5 months ago)
- Topics: ci-cd, cloud-native, cryptocurrency, devops, go, google-cloud-platform, microservices, terraform
- Language: Go
- Homepage:
- Size: 357 KB
- Stars: 2
- Watchers: 2
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.adoc
Awesome Lists containing this project
README
:toc: macro
= Dexly
Cryptocurrency trading bot.
toc::[]
== 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 https://cloud.google.com[account] and
https://cloud.google.com/resource-manager/docs/creating-managing-projects[project].
2. Create a https://cloud.google.com/iam/docs/creating-managing-service-accounts[service account]
for Terraform. For simplicity, give it the project's owner role and generate an
https://cloud.google.com/iam/docs/creating-managing-service-account-keys[account key].
Download the account key and keep it safe, somewhere on your local machine.
3. Install https://www.terraform.io/[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=
```
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 <> section.
Those components are:
- GCR which serves as target repository for images built during the `publish`
job described in <> 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.
// TODO: Complete readme.