Design assignment for GCP K8s (GKE) from currently implemented Docker Compose based solution
Looking for skilled GCP DevOps, with very deep knowledge and daily working experience in GCP environment.
We have a system based on Docker Compose engine with a set of regular services (MongoDB, Redis, etc) and our own custom designed services. All custom designed services are available in our repository (GitLab), and each of them has Docker file for image compilation.
Resources for review of current Docker Compose based architecture:
Offer
Please review in detail the current architecture of the implemented system and the list of works for its transit to the GCP GKE.
If you believe that you are able to implement the list of works within the specified time frame, please contact us and specify the full cost of your services.
-
This is a one-time contract for the implementation of the transition from Docker Compose based solution to GKE. The contract pays a fixed price for a fixed implementation time.
-
After successful GKE implementation, you will have the option to:
-
1.) Become the administrator of the GKE cluster for a fixed monthly fee (react to incidents and fix issues). This job requires 24/7 availability and immediate reaction time.
-
or
-
2.) Become a permanent salaried member of our DevOps team.
-
Required
-
Implement transition of the Docker Compose based solution into GKE.
-
Keep K8s, terraform, etc GKE files in our GitLab repository and setup pipeline for it to GCP
-
Participate in load test (software for the test designed and available)
-
setup <main domain> required records for the GKE (mail service, wiki, etc)
-
Participate in transition from old domain with alive system (Docker Compose based solution) to <main domain> (GKE based) (databases migration, routing setup from old domain to <main domain>)
-
For regular services:
-
Setup required resources in GCP
-
Setup autoscale
-
For our custom designed services:
-
Implement a (CI/CD) pipeline from GitLab into the GKE.
-
Implement autoscale for services required it (horizontal, resources consumption based)
Timeframes is 26 days (+/- 3 days)
GKE services& timeframes for implementation
Phase 1 (timeframes 16 days)
# |
K8s Service |
Requirements/Description |
Subdomain/port for public access |
Time (days) |
Regular services |
||||
1 |
MongoDB |
Two instances (names: iot, data). Horizontally scalable. The service should be available only inside the K8s cluster. Implement backup each day. |
- |
0.5 |
2 |
Redis |
With AOF option off (appendonly yes). The service should be available only inside the K8s cluster. Setup autoscale for resources consumption. |
- |
0.5 |
3 |
MQTT broker |
Horizontally scalable solution for heavy load (15K active clients @ 100 messages/sec). |
<main domain>:8883 |
1 |
4. |
certmanager |
For ssl certificates auto-renewal for main and subdomains of the GKE. |
|
0.5 |
5 |
mailu |
Mail service with UI. Setup, get required keys for <main domain> records (SRV, DKIM, etc). Make admin account. Make support@<main domain> account (required for ‘hts’ (19) service) make no-reply@<main domain> account (required for ‘alert’ (22) service) |
mail.<main domain> |
2 |
6 |
gitbook |
Setup the wiki engine, close public access for make posts, setup admin account. Subdomain ‘wiki’ |
wiki.<main domain> |
0.5 |
7 |
- |
Ticket system for customer service, open-source solution on your choice with API available for internal pods of the GCP K8s for register and manipulate tickets. Subdomain |
ticket.<main domain> |
1 |
8 |
Prometheus + Grafana |
Install services, make admin account, and setup view(s) for brief K8s health review. |
monitor.<main domain> |
1 |
9 |
NGINX/Ingress |
Setup routing. Use settings from nginxCertBotSSL.conf file and docker-compose.yml as reference |
- |
2 |
10 |
GCP solution |
CDN for hold Uis, available for download only in public access, and for upload from GitLab pipeline. Make pipeline in GitLab to separate ui, alpha and betaui |
ui.<main domain> alpha.<main domain> betaui.<main domain> |
0.5 |
Our custom designed services available in company’s GitLab. Each service has its own Docker file. It is required you to setup pipelines from the GitLab to the GCP K8s |
||||
11 |
firmwareUpdate |
Horizontal autoscale via load balancer, CPU/RAM usage. The service has access to CDN (10) with <FW DIRs LIST> directory. |
<main domain>:3333 |
0.5 |
12 |
prod_api |
1 instance, autoscale only CPU/RAM |
production.<main domain> |
0.5 |
13 |
user |
Horizontal autoscale via load balancer, CPU/RAM usage. The service has access to CDN (10) with ‘ui’ directory. |
ui.<main domain> |
0.5 |
14 |
betaui |
Horizontal autoscale via load balancer, CPU/RAM usage. The service has access to CDN (10) with ‘betaui’ directory |
betaui.<main domain> |
0.5 |
15 |
alphaui |
Horizontal autoscale via load balancer, CPU/RAM usage. The service has access to CDN (10) with ‘alpha’ directory |
alpha.<main domain> |
0.5 |
16 |
health |
1 instance, autoscale only CPU/RAM |
- |
0.5 |
17 |
cache |
Connected to CDN volume to ‘cache’ directory, the service available to read and write to the dir. ‘cacheing’ subdomain route to the service, as ‘cacheing’ subdomain public available for read only. Autoscale via load balancer |
cacheing.<main domain> cache.<main domain> |
0.5 |
18 |
calc |
Horizontal autoscale via load balancer |
calculate.<main domain> |
0.5 |
19 |
hts |
1 instance, autoscale only CPU/RAM |
- |
0.5 |
20 |
tlgBot |
1 instance, autoscale only CPU/RAM |
tracker.<main domain> |
0.5 |
21 |
iot |
1 instance, autoscale only CPU/RAM |
iot.<main domain> |
0.5 |
22 |
alert |
1 instance, autoscale only CPU/RAM |
- |
0.5 |
23 |
room_monitor |
1 instance, autoscale only CPU/RAM |
- |
0.5 |
Phase 2 (timeframes 7 days)
Participate in Load test with our custom designed load test software for the GKE solution. Find weak places in implemented GKE and straighten them, tune autoscaler and other settings.
Phase 3 (timeframes 3 days)
Transition from current domain of alive Docker Compose based solution to GKE based solution in <main domain>.