Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content: Cloud module translation #565

Merged
merged 19 commits into from
Mar 12, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 5 additions & 12 deletions .github/pull_request_template.md
Original file line number Diff line number Diff line change
@@ -1,18 +1,11 @@
## What does this change?

<!--delete and update as appropriate-->

### Common Content?
# WARNING MAJOR STRUCTURAL CHANGE IN PROGRESS 12 JAN 2024

Block/s
Hello contributor! In between you opening this PR and you merging it, you may find a large conflict appears. This is because this site will be broken down into Hugo modules in the same way CodeYourFuture/curriculum-labs is currently structured. The platform (features) will move into the common-theme module and the content (text) will move into the common-content module. The pages will move into the organisation directory. (org-cyf for CYF and org-mcb for MigraCode) You will need to find the new location of your content and move it there. If you are unsure, please ask in the comment thread of this ticket.

### Common Theme?

Issue number: #issue-number

### Org Content?
## What does this change?

Module | Sprint | Page Type | Block Type
Module:
Week(s):

## Checklist

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ time=45

(If you don't have a guest expert, do study group instead.)

Share your questions in a Slack thread by Friday 10am. This is an {{<tooltip title="Ask Me Anything">}}
Share your questions in a Slack thread by Friday 10am. This is an {{<tooltip title="AMA">}}
[Ask Me Anything](https://www.businessinsider.com/guides/tech/ama-meaning).
{{</tooltip>}} style session.

Expand Down
55 changes: 55 additions & 0 deletions common-content/en/module/cloud/actions/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
+++
title = 'Learning GitHub Actions Basics'
headless = true
time = 20
facilitation = false
emoji= '🧩'
[objectives]
1='Describe GitHub Actions workflows, jobs, steps, and actions.'
2='Set up a basic CI/CD pipeline using GitHub Actions in a GitHub repository'
3='Write a YAML file that specifies the actions to be taken when code is pushed to the repository'
+++

### What are GitHub Actions?

GitHub Actions is an automation framework that runs in your GitHub repository. It can build, test, and deploy your code right from GitHub.

#### Key Components

1. **Workflows**: Orchestrates your CI/CD process.
1. **Jobs**: Sets of steps that execute sequentially.
1. **Steps**: Individual tasks within a job.
1. **Actions**: Pre-built steps that you can use in your jobs.

{{<note type="activity" title="Review a GitHub action">}}

Github Actions have been present in the course, now we are going to take a look at them and review them.

You may have opened a PR for this repo. Find your pull request and read the Github Action workflow. Go to <https://github.com/CodeYourFuture/JavaScript-Core-1-Coursework-Week1> to find your Pull Request or go directly to the Actions <https://github.com/CodeYourFuture/JavaScript-Core-1-Coursework-Week1/actions> to find your workflow run.

If you haven't opened a PR to this repo, find the one by [NAME]

{{</note>}}

## Setting up a Simple Workflow

To set up a simple GitHub Actions workflow, navigate to your GitHub repository and then to the Actions tab. From there, you can create a new workflow.

Here's a basic example:

```yaml
name: CI

on: [push]

jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
```

This YAML file specifies a single job called build that runs on an ubuntu-latest runner machine. The job has a single step that uses actions/checkout@v3 to download the code from the GitHub repository.

For more information on Github Actions Syntax refer to their documentation: <https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions>
44 changes: 44 additions & 0 deletions common-content/en/module/cloud/alerts-and-metrics/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
+++
title = 'Creating Alerts and Understanding Metrics'
headless = true
time = 20
facilitation = false
emoji= '🧩'
[objectives]
1='Create an alert in Cloudwatch'
+++

Alerting is a key aspect of monitoring; it allows you to know in real-time if something goes wrong or if a certain performance threshold has been met or exceeded. By creating alerts, you make your system more resilient and reduce the time needed to respond to incidents.

### Creating Alerts with AWS CloudWatch

[AWS CloudWatch](https://aws.amazon.com/cloudwatch/) provides a feature to set up alerts based on specific conditions or thresholds. These alerts can then be forwarded to other AWS services like SNS for notifications via email, SMS, or other methods.

To create an alert in CloudWatch:

1. Open the CloudWatch console in your AWS Management Console.
2. In the navigation pane, choose "Alarms," then choose "Create Alarm."
3. Choose "Select metric" and specify the metric and conditions for your alarm.

```bash
# AWS CLI example to create a CPU utilization alarm for an EC2 instance
aws cloudwatch put-metric-alarm --alarm-name cpu-high --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 300 --threshold 70 --comparison-operator GreaterThanThreshold --dimensions Name=InstanceId,Value=i-12345678 --evaluation-periods 2
```

### Metrics to Monitor in EC2 and RDS

#### EC2

- **CPU Utilization**: Measures the compute power required by an EC2 instance.
- **Disk Read/Writes**: Monitors the read and write operations on the instance storage.
- **Network In/Out**: Measures the network traffic to and from the instance.

[More on EC2 CloudWatch Metrics](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html)

#### RDS

- **CPU Utilization**: Measures the compute power used by your database instance.
- **Database Connections**: The number of database connections in use.
- **Free Storage Space**: Monitors the available storage space of your database instance.

[More on RDS CloudWatch Metrics](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MonitoringOverview.html)
15 changes: 15 additions & 0 deletions common-content/en/module/cloud/ci-cd/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
+++
title = '🛬 What is CI/CD?'
headless = true
time = 5
facilitation = false
emoji= '🛬'
[objectives]
1='Define CI and CD'
+++

**CI**, or Continuous Integration, is a development practice where developers integrate code into a shared repository frequently. This usually happens multiple times a day and is complemented by automated tests.

**CD**, or Continuous Deployment/Delivery, takes the code changes from a repository, automatically builds and tests them, and then automatically deploys the tested code to a live service.

These practices make it easier to catch bugs earlier and make deployments faster and more reliable.
30 changes: 30 additions & 0 deletions common-content/en/module/cloud/deployment-stage/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
+++
title = 'Adding Deployment Stages'
headless = true
time = 5
facilitation = false
emoji= '🧩'
[objectives]
1='Integrate deployment scripts into the GitHub Actions workflow'
+++

Once your code has been built and tested, you can deploy it automatically using GitHub Actions.

Here's a simplified example:

```yaml
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Deploy
run: npm deploy
```

In this example, we use a custom command script for deploy. In your package.json you will have a section for scripts:

```json
"scripts": {
"deploy": "echo this is a deploy",
}
```
37 changes: 37 additions & 0 deletions common-content/en/module/cloud/environment-variables/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
+++
title = 'Environment Variables'
headless = true
time = 20
facilitation = false
emoji= '🧩'
[objectives]
1='Automate the deployment process to a specified environment.'
+++

In any development workflow, especially one that involves deployments, it's common to have configuration settings that should not be hard-coded in the codebase. This includes API keys, database URLs, and other sensitive information. GitHub Actions allows the use of environment variables and secrets to manage these configurations securely.

#### Github Environment Variables

Environment variables are key-value pairs that you can create and modify as part of your workflow. They can be accessed in your GitHub Actions YAML file via env context. For example, to set a Node.js environment, you can do:

```yaml
jobs:
build:
runs-on: ubuntu-latest
env:
NODE_ENV: production
```

And then use it in a script like this:

```yaml
- name: Using Environment Variable
run: echo Node environment is ${{ env.NODE_ENV }}
```

{{<note type="activity" title="Try it yourself">}}

1. Create an `.env` file in the root of your working repo
1. ETC TODO

{{</note>}}
59 changes: 59 additions & 0 deletions common-content/en/module/cloud/multiple-jobs/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
+++
title = 'Creating a Workflow with Multiple Jobs'
headless = true
time = 15
facilitation = false
emoji= '🧩'
[objectives]
1='Implement a multi-job workflow where jobs run sequentially, based on dependencies and requirements'
2='Use the needs keyword to specify job dependencies'
+++

In a real-world scenario, you often need multiple jobs to run different tasks in parallel or sequentially to speed up the process or manage dependencies. In this section, you'll learn how to set up a workflow with multiple jobs.

#### Example: npm test and Deployment

Here's an example YAML configuration file for a GitHub Actions workflow that has two jobs: one for running tests and another for deployment.

```yaml
name: CI/CD Pipeline

on: [push]

jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Install Dependencies
run: npm install
- name: Run tests
run: npm test

deploy:
needs: test
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Deploy
run: npm deploy
```

### Understanding the Workflow

1. **jobs**: Contains two job blocks: test and deploy.
1. **runs-on**: Specifies the type of runner that the job will run on.
1. **steps**: The sequence of tasks that will be executed in each job.
1. **needs**: This key in the deploy job specifies that it needs the test job to complete successfully before it starts.

By defining both jobs in the same YAML file, GitHub Actions will know to run them as part of the same workflow. The `needs` keyword ensures that the deploy job will only run if the test job completes successfully. We add a layer of protection against bugs making their way into production.

And that's how you set up a GitHub Actions workflow with multiple jobs. This allows you to make your CI/CD process more robust and maintainable.

{{<note type="activity" title="Sequence your jobs">}}

In your working repo, add your deploy stage to your test stage.

{{</note>}}
48 changes: 48 additions & 0 deletions common-content/en/module/cloud/scalability-cloud/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
+++
title = 'Implementing Scalability in the Cloud'
headless = true
time = 15
facilitation = false
emoji= '🧩'
[objectives]
1='Identify a strategy for achieving vertical scaling with AWS RDS'
2='Explain how to use horizontal autoscaling with AWS EC2'
+++

Implementing scalability in the cloud involves various strategies and technologies that help you adapt to the demands of your user base and workloads. Below are some popular methods for achieving scalability in the cloud using AWS services.

### Horizontal Scaling and Vertical Scaling

#### Horizontal Scaling with AWS EC2

In horizontal scaling, additional instances are added to or removed from a resource pool as needed. AWS EC2 offers Auto Scaling Groups that allow you to scale the number of EC2 instances up or down automatically based on pre-defined conditions such as CPU usage or incoming network traffic.

```bash
# AWS CLI command to update an existing Auto Scaling group
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg --min-size 1 --max-size 5
```

#### Vertical Scaling with AWS RDS

AWS RDS allows you to resize your database instances to better meet your application's needs. For instance, you could switch from a `db.t2.micro` to a `db.m4.large` instance type, thus vertically scaling your database.

```bash
# AWS CLI command to modify an RDS instance
aws rds modify-db-instance --db-instance-identifier mydbinstance --db-instance-class db.m4.large
```

### Load Balancing with AWS ELB

AWS Elastic Load Balancer (ELB) distributes incoming traffic across multiple EC2 instances. ELB can be an essential part of both horizontal and vertical scaling strategies.

### Elasticity and Provisioning with AWS S3

AWS S3 is designed to scale automatically. It automatically partitions your buckets as they grow, without any need for manual intervention. S3 also offers provisioned capacity for demanding workloads.

### State Management in AWS RDS

Managing state in scalable systems is crucial. AWS RDS supports Multi-AZ deployments enhancing high availability and failover support for DB instances.

For more detailed information on AWS scalability strategies, you can refer to the [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/).

By understanding and implementing these AWS-specific concepts, you'll be better prepared to build scalable and reliable cloud-based applications.
32 changes: 32 additions & 0 deletions common-content/en/module/cloud/scalability-monitoring/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
+++
title = 'Monitoring Tools'
headless = true
time = 20
facilitation = false
emoji= '🧩'
[objectives]
1='List the benefits of monitoring'
2='Define observability'
+++

Monitoring is crucial for understanding the behavior of your applications and infrastructure, particularly in cloud environments where many components work together to deliver an application. Monitoring not only helps you to diagnose and fix issues faster, but it also plays a pivotal role in optimizing performance and planning for scalability.

### Why is Monitoring Important?

- **Performance Tuning**: Real-time data helps you understand how well your system is performing and where bottlenecks may be forming.

- **Issue Identification**: Proactive monitoring can alert you to issues before they impact your users, allowing for quicker resolution.

- **Security**: Monitoring can help identify unauthorized access or anomalies that could indicate a security breach.

### Observability

Observability is the ability to understand the internal state of your system just by examining its outputs. An observable system makes it easier to identify the root causes of failures and debug or optimize code. Observability is often considered the superset of monitoring, logging, and other diagnostic activities.

### Monitoring with AWS CloudWatch

[AWS CloudWatch](https://aws.amazon.com/cloudwatch/) is a robust monitoring solution that allows you to collect and track metrics, collect and monitor log files, and set alarms. CloudWatch can monitor AWS resources like EC2 instances, RDS databases, and S3 buckets, as well as custom metrics generated by your applications.

Using AWS CloudWatch, you can create dashboards to visualize metrics, set thresholds for alarms, and even automatically react to changes in your AWS resources.

By setting up monitoring tools and learning the importance of observability, you are taking proactive steps to maintain high availability and performance of your cloud services and applications.
22 changes: 22 additions & 0 deletions common-content/en/module/cloud/scalability-types/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
+++
title = 'Types of scalability'
headless = true
time = 5
facilitation = false
emoji= '🧩'
[objectives]
1='Identify the difference between vertical and horizontal scaling'
+++

#### Vertical Scaling

Also known as "scaling up," this involves adding more resources like CPU, RAM, or storage to an existing server. While easy to implement, there are physical limits to how much you can scale vertically.

#### Horizontal Scaling

Also known as "scaling out," this involves adding more servers to share the application's load. This is often considered more flexible but can be complex to manage.

## 📚 Resources

- [Scalability](https://en.wikipedia.org/wiki/Scalability)
- [Vertical vs. Horizontal Scaling](https://www.ibm.com/cloud/learn/scaling-horizontally-vs-vertically)
Loading
Loading