WIP.3 Week 1
This commit is contained in:
parent
5f121dab4e
commit
e0ac417365
139
week1.md
139
week1.md
@ -1,4 +1,4 @@
|
|||||||
## Project Context: PetCLinic Microservices -> AWS
|
# Project Context: PetCLinic Microservices -> AWS
|
||||||
|
|
||||||
## Context and Scope
|
## Context and Scope
|
||||||
|
|
||||||
@ -121,7 +121,7 @@ This project will migrate the Spring PetClinic Microservices demo from its local
|
|||||||
- Security
|
- Security
|
||||||
- Resilience
|
- Resilience
|
||||||
- Observability
|
- Observability
|
||||||
- Assignments:
|
#### Assignments:
|
||||||
|
|
||||||
| Role | Responsibilities |
|
| Role | Responsibilities |
|
||||||
|----|----|
|
|----|----|
|
||||||
@ -135,8 +135,141 @@ This project will migrate the Spring PetClinic Microservices demo from its local
|
|||||||
|
|
||||||
### Source Code
|
### Source Code
|
||||||
|
|
||||||
- Architecture Type: Microservices deployed via containers, managed by ECS/EKS, behind an AWS Application Load Balancer (ALB).
|
- Architecture Type: Microservices deployed via containers, managed by ECS, behind an AWS Application Load Balancer (ALB).
|
||||||
- Review via pull request process:
|
- Review via pull request process:
|
||||||
- All commits merged via PRs.
|
- All commits merged via PRs.
|
||||||
- Peer review required before merging.
|
- Peer review required before merging.
|
||||||
- Vaildation: Run tests during pipeline build
|
- Vaildation: Run tests during pipeline build
|
||||||
|
|
||||||
|
## CI/CD
|
||||||
|
|
||||||
|
- Goal: Automate the entire software delivery process for all PetClinic microservices via Jenkins
|
||||||
|
|
||||||
|
### Development Cycle Stages
|
||||||
|
|
||||||
|
| Stage | Description |
|
||||||
|
|----|----|
|
||||||
|
| **01. Code & Merge** | Developer writes code and merges it with the staging branch |
|
||||||
|
| **02. Build** | Compile, resolve dependencies |
|
||||||
|
| **03. Unit Test** | Run service-level tests |
|
||||||
|
| **04. Containerize** | Build Docker image for service |
|
||||||
|
| **05. Security Scan** | Security validation via Trivy |
|
||||||
|
| **06. Push to Registry** | Push validated image |
|
||||||
|
| **07. Deploy to Staging** | Deploy for validation |
|
||||||
|
| **08. Integration tests** | Validate service communication|
|
||||||
|
| **09. Deploy to Production** | Promote validated build |
|
||||||
|
| **11. Observability Check** | Validate monitoring and alerts |
|
||||||
|
|
||||||
|
### Jobs and environments
|
||||||
|
|
||||||
|
- Each microservices has his own Jenkins pipeline
|
||||||
|
|
||||||
|
| Environment | Purpose | Infrastructure | Notes |
|
||||||
|
|----|----|----|----|
|
||||||
|
| **Development (Local)** | Local testing, feature validation | Docker Compose | Developer workstations |
|
||||||
|
| **Staging (AWS)** | Integration and pre-prod testing | ECS/EKS (staging cluster), RDS (test DB) | Mirrors production |
|
||||||
|
| **Production (AWS)** | Live system | ECS/EKS (prod cluster), RDS (prod DB) | Monitored|
|
||||||
|
|
||||||
|
## Storage
|
||||||
|
|
||||||
|
### 1. Database (RDBMS)
|
||||||
|
|
||||||
|
- Service: Amazon RDS (MySQL)
|
||||||
|
- IOPS: 3,000–6,000 (gp3 default) or provisioned as needed
|
||||||
|
- Volume: 20 GB per microservice schema
|
||||||
|
- Backup: Automated daily snapshots (14 day retention)
|
||||||
|
|
||||||
|
### 2. Block Storage
|
||||||
|
|
||||||
|
- Service: Amazon EBS (gp3)
|
||||||
|
- Use: EC2-hosted Jenkins, logs, or stateful containers
|
||||||
|
- IOPS: 3,000 baseline
|
||||||
|
- Backup: Not necessary
|
||||||
|
|
||||||
|
### 3. Object Storage
|
||||||
|
|
||||||
|
- Service: Amazon S3
|
||||||
|
- Use: Logs, backups, images
|
||||||
|
- Performance: Standard or Infrequent Access tiers
|
||||||
|
- Backup: Cross-region replication or versioning enabled
|
||||||
|
|
||||||
|
## Data
|
||||||
|
|
||||||
|
### 1. Location
|
||||||
|
- Eu-central-1 region
|
||||||
|
- Place database (RDS) and services in the same region and AZs for low latency.
|
||||||
|
|
||||||
|
### 2. Replication / Distribution
|
||||||
|
| Data Type | Replication / Distribution Strategy |
|
||||||
|
|----|----|
|
||||||
|
| **RDS (Postgres/MySQL)** | Multi-AZ synchronous replication |
|
||||||
|
| **S3 (images, artifacts)** | Automatic cross-AZ durability |
|
||||||
|
|
||||||
|
### 3. Links / Access
|
||||||
|
|
||||||
|
| Access type | Route|
|
||||||
|
|----|----|
|
||||||
|
| **Internal** | Microservices access RDS via private VPC links. |
|
||||||
|
| | Images in S3 accessed via IAM roles or pre-signed URLs. |
|
||||||
|
| **External** | ALB routes external requests. |
|
||||||
|
| | HTTPS enforced for secure data transfer. |
|
||||||
|
|
||||||
|
## Network
|
||||||
|
|
||||||
|
### Location
|
||||||
|
|
||||||
|
- Eu-central-1 region
|
||||||
|
- Deploy services across multiple AZs for high availability.
|
||||||
|
- All microservices, databases, and supporting infrastructure live inside a single VPC.
|
||||||
|
- Isolate the network from public internet by default
|
||||||
|
|
||||||
|
### Network Segmentation & Filtering
|
||||||
|
- Public subnets: For ALB ,NAT gateway if needed.
|
||||||
|
- Private subnets: For ECS/EKS tasks, RDS, Config Server, and internal microservices.
|
||||||
|
- Security groups: Service-specific firewall rules
|
||||||
|
- Tweak default ACLs if necessary
|
||||||
|
|
||||||
|
### Addressing
|
||||||
|
|
||||||
|
- VPC: `10.0.0.0/16`
|
||||||
|
- Public subnet: `10.0.1.0/24`
|
||||||
|
- Private subnet: `10.0.2.0/24`
|
||||||
|
- Every service/database gets a internal IP in the private subnet
|
||||||
|
- Only load balancer or NAT gateway have public IP
|
||||||
|
|
||||||
|
## Compute
|
||||||
|
|
||||||
|
### Nodes
|
||||||
|
|
||||||
|
| Environment | Nodes | Notes |
|
||||||
|
|----|----|----|
|
||||||
|
| **Staging** | 3 ECS container instances (EC2) | Handles staging microservices, mirrors production setup |
|
||||||
|
| **Production / Live** | 3 ECS container instances (EC2) | Fixed-size cluster, no autoscaling to reduce costs |
|
||||||
|
| **Scalability** | N/A for autoscaling | Fixed node count to reduce cost but still allow horizontal scaling via ECS task count or manual node addition. |
|
||||||
|
|
||||||
|
### Container Management
|
||||||
|
|
||||||
|
#### Container Registry:
|
||||||
|
- Amazon ECR for all microservice Docker images.
|
||||||
|
- Each microservice image tagged by Git commit SHA.
|
||||||
|
|
||||||
|
#### Microservice Packaging:
|
||||||
|
|
||||||
|
- Dockerized images for each service.
|
||||||
|
- Multi-stage Docker builds to reduce image size.
|
||||||
|
|
||||||
|
#### Deployment Strategy:
|
||||||
|
|
||||||
|
- ECS tasks run one or more containers per node.
|
||||||
|
- Service definitions ensure each microservice has the desired number of tasks.
|
||||||
|
- Jenkins updates ECS service definition after build.
|
||||||
|
|
||||||
|
### ECS Orchestration
|
||||||
|
|
||||||
|
#### Cluster Setup:
|
||||||
|
- One ECS cluster per environment (staging and production).
|
||||||
|
- EC2 launch type for fixed nodes.
|
||||||
|
|
||||||
|
#### Service Definitions:
|
||||||
|
- Each microservice has an ECS service with a desired task count.
|
||||||
|
- Service linked to ALB .
|
||||||
Loading…
x
Reference in New Issue
Block a user