HLD011 - Artifact Storage
Introduction
Purpose
The purpose of this document is to outline a high-level design architecture for artifact storage, that will store images, helm charts and code libraries.
Requirements
Docker/Helm registry:
AWS ECR
Scanning using AWS Inspector
Cache/Proxy for imaged pulled from public registries;
Support for DockerHub, Google Container Registry;
Registry per system (app);
Support for manifest bundled with image
Images will be signed by client keys (T-Mobile) - TBD, might change in the future;
ECR MUST decline unsigned images
Helm - TBD
Code artifacts:
Versioning is a MUST
Minimal support for: MVN, NPM, Python, and ZIP
No need to scan artifacts/packages - everything will be used for image building, images can be scanned by AWS Inspector
Every system (application) dependencies need to be separated from each other:
Developers of system A have access to libraries/dependencies/artifacts used in system A
Support for fine-grained access using ABAC
Changelog
Revision | Date | Description |
|---|---|---|
| 23.07.2024 | Initial document |
Background
Artifact storage is an integral part of software development and deployment processes. In the solution, we will have to handle two variants of artifacts. The first one - the application image - will be stored in AWS ECR (Elastic Container Registry), which is a fully managed container registry service that allows us to store, manage, and deploy container images. It is specifically designed for containerized applications and integrates seamlessly with other AWS services like Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service (EKS), and AWS Fargate. It supports Docker Image Manifest V2 Schema 1 and 2, and Open Container Initiative (OCI)specifications - >=1.0.
Second type of artifact - the code artifact - will be stored in AWS S3, which is a highly scalable object storage service offered by Amazon Web Services (AWS). It serves as a reliable and cost-effective solution for storing and retrieving artifacts such as files, documents, images, videos, backups, and more, which makes it perfect service for storing software artifacts. It is supported by a variety of package managers (support varies from built-in to trough plugin), including npm (for Node.js), PyPI (for Python), Maven (for Java), and NuGet (for .NET).
Architecture diagram
Explanation
ECR and S3 Endpoints will be deployed on Frankfurt AWS Region (
eu-central-1);Images and code dependencies (libraries/packages/archives) are stored inside ECR and S3;
Every application will use a separate repository/bucket defined inside terraform deployment;
Permissions to each repository/bucket, in both S3 and ECR, will be granted using tags (ABAC);
Versioning is supported by default (on ECR it is done trough tagging);
ECR can cache resources from Amazon ECR Public, Quay, and the Kubernetes container image registry;
ECR is continuously scanned by AWS Inspector with configured automated remediation;
Images will be signed free of cost by AWS Signer; providing custom key is not allowed;
Pricing
Considerations
ECR* Stora $0.10/GB Private Repository Data Transfer IN* $0.00/GB Private Repository Data Transfer OUT* <$0.09/GB; price decreases every several dozen TB used in a month Public Repository Data Transfer IN* $0.00/GB Public Repository Data Transfer OUT* <$0.00/GB up to 5TB/mo; $0.09/GB afterward S3 Storage <$0.0245/GB; can be cheaper by using storage class depending on given object access pattern Data Transfer IN $0.00/GB Data Transfer OUT <$0.09/GB; price decreases every several dozen TB used in a month $0.02/GB to AWS Regions $0.00/GB for CloudFront Inspector Images scanned on-push to ECR $0.09/image/month Automated rescans for images in ECR $0.01 per rescan
ECR* | Store | ||||
|---|---|---|---|---|---|