Skip to content
Snippets Groups Projects
Commit 20326166 authored by ewbo4360's avatar ewbo4360 :sunflower:
Browse files

Pipeline updated to build and publish artifacts to GitLab that remain... 

Pipeline updated to build and publish artifacts to GitLab that remain accessible for 5min to any user on the root/artifacts directory, matrix usage for multiplatforms build will be possible eventually in further versions
parent 6deb210a
No related branches found
No related tags found
No related merge requests found
Pipeline #74510 passed
Stage: build
Stage: test
Stage: publish
Hide whitespace changes
Inline Side-by-side
Showing
with 1 addition and 158 deletions
CONCEPT.md
+ 1
− 158
View file @ 20326166
Warning : In this file we only express the life cycle and the way of maintaining our app for the DevOps project. To learn about what it actually does please refer to the README.md at the root of this project.
Also for the moment the pipeline runs only as if Linux was the only available target.
# Formal
- **Hand in a deep link** to the file(s) located in that repository
# Content
## Life Cycle of the Application
The application we want to maintain has to be handled following the DevOps concepts learnt during lectures and exercices.
......@@ -57,155 +51,4 @@ The life cycle of this app is handled through many tools and methods that we dev
In one hand, for containers and container images purpose, the service we'll use is Docker for flexibility between building and running purposes.
In the other hand, for virtualization purpose, we use Virtual Box for its user friendly usage but also because I used it many times before as I often needed Linux hotsed machine but my personal computer's OS is win10. Finally it's the one that was used during the lectures for demonstration.
Outline the architecture of your infrastructure and how it will be provisioned. This should include:
- High-level overview of infrastructure components (e.g., load balancers, VMs, containers)
- Description of how each component is provisioned, whether manually or automatically (e.g., using Infrastructure as Code tools like Terraform or CloudFormation)
## Decision Explanation
Explain the decisions you made throughout the project, focusing on the rationale behind your choices. Include:
- Why certain technologies or frameworks were chosen over others
- Trade-offs made between cost, performance, scalability, and maintainability
- The benefits and challenges of the selected technology stack
## Technology Stack
1. **Programming language**
Except for some build, configuration and miscellaneous files the Programming langage used in this applciation is C++. Mainly for its user friendly usage but still close to the machine. This langage is also the one I know the better and that I value the most.
2.
Briefly describe the technology stack you opted for and why. This may include:
- Programming languages
- Databases
- CI/CD tools
- Containerization/orchestration (e.g., Docker, Kubernetes)
- Cloud providers or infrastructure (e.g., AWS, Azure, GCP)
# Additional Questions for Inspiration
Our infrastructure is hosted on Amazon Wed Services cloud to be able to access our project infrastructure with any well protected web browser.
- **The CI/CD runners are hosted by Gitlab.com**
-**I use Jira for personal Project Managment because I got used to it in a previous internship**
-**CI/CD is communicating through the GitLab CI/CD system through the commits on the local branches that directly send information to run a pipeline routine following the .gitlab-ci.yml file**
<!--
- **Where is your infrastructure hosted?**
- **How do you allocate the underlying resources hosting your environments?**
- **How is everything provisioned?**
- **Why did you choose one technology over another?**
- **How does CI/CD talk to the Version Control System (VCS) and/or vice versa?**
- **What are the names of your target environments?**
- **How do you set up all your services? Which ones do you actually need to set up? If some services don’t need to be set up, why?**
- **What are the differences between your environments, if any?**
- **Would graphics or diagrams help illustrate your architecture?**
- **What about the persistence layer (database)?**
//////////////////////////////////////////////////////////////////////////////////////////////////:::
# Content
## Life Cycle of the Application
The life cycle of this application is designed to be as automated and repeatable as possible. Below are the key steps of the process:
1. **Development Phase**:
- Developers write code using the selected technology stack.
- Each feature branch is created from the main branch in Git.
- Code is committed regularly and pushed to the remote repository.
2. **Continuous Integration (CI)**:
- When code is pushed to the repository, the CI pipeline (set up in GitHub Actions or GitLab CI) triggers automatically.
- The pipeline runs tests, lints the code, and builds the project to ensure that no errors or regressions are introduced.
3. **Continuous Deployment (CD)**:
- Upon successful integration, the CD pipeline automatically deploys the application to a staging environment.
- Once verified, the application is deployed to production.
- Any issues that arise in production are flagged in the monitoring systems and resolved through additional commits.
4. **Monitoring and Feedback**:
- Real-time logging and monitoring services (e.g., Prometheus, Grafana) collect performance and error data.
- This feedback loop ensures continuous improvements and bug fixing.
## Infrastructure Architecture and Provisioning
The infrastructure for this application is provisioned and managed using the following tools and services:
1. **Cloud Provider**:
- The infrastructure is hosted on **AWS (Amazon Web Services)**, leveraging its elasticity and scalability features.
2. **Infrastructure as Code (IaC)**:
- We use **Terraform** for provisioning and managing cloud resources. Terraform scripts define and automate the setup of virtual machines (EC2 instances), databases (RDS), and networking (VPC).
3. **Containerization**:
- The application is packaged into **Docker containers** to ensure consistency across development, staging, and production environments.
- **Kubernetes** is used for orchestration and management of containerized applications, allowing for easy scaling, load balancing, and fault tolerance.
4. **Continuous Deployment Pipeline**:
- A CI/CD pipeline using **GitHub Actions** ensures that code is automatically built, tested, and deployed.
- Deployment to staging and production is handled by Terraform using the `terraform apply` command to provision infrastructure and deploy the application.
## Explanation of Decisions
- **AWS vs. Azure/GCP**: We chose **AWS** as our cloud provider because of its well-established services, broad documentation, and flexibility in offering services that suit our project needs (e.g., EC2, RDS, EKS).
- **Docker & Kubernetes**: Containerization with **Docker** ensures that the application runs consistently across all environments. **Kubernetes** was selected for container orchestration due to its scalability and ability to manage the complexity of deploying applications at scale.
- **Terraform for IaC**: Terraform was chosen for infrastructure management due to its support for multi-cloud environments, flexibility in resource provisioning, and the fact that it integrates seamlessly with both AWS and Kubernetes.
- **GitHub Actions for CI/CD**: GitHub Actions offers native integration with GitHub repositories, making it the most suitable option for automated builds, tests, and deployments. It also supports flexible workflows and can trigger actions based on events in the repository (like a push or pull request).
## Technology Stack
The technology stack for this application was selected based on scalability, cost-efficiency, and familiarity with the development team. Here’s a breakdown:
1. **Programming Language**: **Node.js** (JavaScript) is used for the application’s back end, as it offers asynchronous, event-driven architecture that is well-suited for scalable, high-performance applications.
2. **Database**: We are using **Amazon RDS (PostgreSQL)** for data persistence. PostgreSQL was chosen for its reliability, support for ACID transactions, and compatibility with relational data models.
3. **Containerization**:
- **Docker** is used to containerize the application, ensuring consistency between development, staging, and production environments.
- **Kubernetes (EKS)** is used for orchestrating Docker containers at scale on AWS.
4. **CI/CD**:
- **GitHub Actions** for Continuous Integration and Continuous Deployment ensures that the code is automatically tested, built, and deployed.
5. **Monitoring**:
- **Prometheus** and **Grafana** are used for real-time monitoring, providing detailed insights into system performance and uptime.
## Additional Considerations
### Where is your infrastructure hosted?
- The infrastructure is hosted on **AWS** to leverage the scalability and managed services offered by Amazon, including EC2 instances, RDS for database management, and EKS for container orchestration.
### How do you allocate the underlying resources hosting your environments?
- Resources are allocated dynamically using **Terraform**, which provisions and manages resources like EC2 instances, RDS instances, and VPC networks. We can scale resources up or down as needed based on the traffic and load.
### How is everything provisioned?
- **Terraform** scripts are used to automate the provisioning of the infrastructure and deployment of the application. This includes configuring the networking layer, databases, and Kubernetes clusters, ensuring a repeatable and predictable deployment process.
### Why did you choose one technology over the other?
- **Node.js** was chosen for its asynchronous, non-blocking I/O model, making it suitable for real-time applications.
- **AWS** was selected because of its robust set of cloud services, wide adoption, and support for scaling applications.
- **Terraform** is chosen for its flexibility and ability to work with multiple cloud providers, allowing for easy replication and management of infrastructure.
### What are the names of your target environments?
- **Development**: For local development environments and initial testing.
- **Staging**: A replica of the production environment used for testing new features.
- **Production**: The live environment where users interact with the application.
### How do you set up all your services?
- Services are set up through automated pipelines in **GitHub Actions**. The CI pipeline ensures the code is built and tested, while the CD pipeline automatically deploys it to staging and production environments using Terraform and Kubernetes.
### What are the differences between your environments, if any?
- **Development** is usually a local environment where developers run services in containers using Docker. **Staging** mimics the production environment, with an identical configuration to test changes before pushing them live. **Production** has additional monitoring and scaling configurations to handle real-world traffic.
### Would some graphic(s) better illustrate your architectural design?
- Yes, including diagrams of the architecture, CI/CD pipelines, and Kubernetes cluster setup would help visualize how the components interact.
### What about the persistence layer (database)?
- The **PostgreSQL** database is hosted on **Amazon RDS** for high availability, automatic backups, and scalability. It supports the application’s relational data model and is fully managed, reducing overhead for maintenance and administration.
-->
In the other hand, for virtualization purpose, we use Virtual Box for its user friendly usage but also because I used it many times before as I often needed Linux hotsed machine but my personal computer's OS is win10. Finally it's the one that was used during the lectures for demonstration.
\ No newline at end of file
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment