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

[EXTERNAL] added test task and serverless task #2707

Merged
5 changes: 5 additions & 0 deletions employment-tasks/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
# Test tasks from the real job interviews

This folder is used to store test tasks from the real job interviews. The tasks are stored in the `test-tasks` folder. Each task is stored in a separate folder with the name of the company that provided the task. Inside the company folder, there is a `README.md` file with the task description.

The real job interviews prepare students and junior specialists for the real job interviews. The tasks are designed to test the knowledge and skills of the candidates. The tasks are usually taken from the job position interviews and the company's technology stack.
37 changes: 37 additions & 0 deletions employment-tasks/devops/basic-api/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# Site Reliability Engineer - Basic API Hosting Task

## Part 1 – The Web Service

Write a web service in any language that takes in a JSON payload, does
some basic validation against an expected message format and content,
and then puts that payload into a queue of your choice or a file.

Example valid payload:
```json
{
"ts": "1530228282",
"sender": "curler-user",
"message": {
"foo": "bar",
"hash": "bash"
},
"sent-from-ip": "1.2.3.4"
}
```

Validation rules:
● “ts” must be present and a valid Unix timestamp
● “sender” must be present and a string
● “message” must be present, a JSON object, and have at least one
field set
● If present, “sent-from-ip” must be a valid IPv4 address
● All fields not listed in the example above are invalid, and
should result in the message being rejected.

## Part 2 – Terraform

Deploy this application to your favourite cloud provider using Terraform.

## Part 3 – NewRelic

Implement NewRelic monitoring for this application using Terraform.
23 changes: 23 additions & 0 deletions employment-tasks/devops/notbad-task/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Senior DevOps Engineer - NotBad Header based API

Look at the following tasks and estimate how much time you will spend on them.

## Preconditions

### Technical & Knowledge
You need at least:

* Experience with AWS stack
* Experience with CI/CD
* Experience with Bash scripts
* Experience in at least one programming language (Java, Python, PHP, Perl, etc.)
* A text editor of your choice

## The tasks
1) We have a Terraform securitygroups.tf file. Every time Terraform runs, it says the security group in that file will be updated in place. Find a way to prevent this.

2) You have the keycloak-test.tar.gz archive. What we can improve?

3) Provide infrastructure and create CI/CD with a web app that will listen to 8089 port and return "ReallyNotBad" string when POST request contains header "NotBad" with value "true", eg. `curl -X POST -H "NotBad: true" https://someurl:8089/` should return "ReallyNotBad".
Use any technology you want to deploy the application to AWS. It can be Ansible, Terraform, etc. or a combination of some of them.
Hint: https://aws.amazon.com/free/
Binary file not shown.
66 changes: 66 additions & 0 deletions employment-tasks/software-engineer/game-task/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
## Software Engineer - Game Task

### Tools and technologies used:

1. Go
2. PostgreSQL
3. Docker
4. Makefile
5. Postman

All database tables are in `migrations` folder. To run them, use `make` command.

1. `make migrate-up` - to run up migrations
2. `make migrate-down` - to run down migrations
3. `make migrate-force` - to force run migrations if you have some errors like `error: Dirty database version -1. Fix and force version.`

### Tables:

1. `users` - contains users data
2. `transaction` - contains transactions data

### Endpoints to test:

1. `GET /users` - to get all users
2. `GET /users/{user_id}` - to get user by id, check his balance
3. `GET /transactions/{user_id}` - to get all transactions by user id (check if user has any transactions)
4. `POST /process-record/{user_id}` - to process record by user id

Process record request body example:

```
{
"amount": 10,
"transaction_id": "64338a05-81e5-426b-b01e-927e447c9e33",
"state": "win"
}
```

Transaction id is unique, so you can't process the same transaction twice, provide UUID v4 format.
State can be `win` or `lose`.
Amount is a number should be positive but to have a negative balance you should provide a `lose` state.

### Required header for all endpoints:

1. `Source-Type: game` - available values: `game`, `server`, `payment`

Postman collection is in `postman` folder to test endpoints.

## To run the app locally:

1. Create `.env` file in root folder and add all required variables from `.env.example` file
2. To run migrations you should have migrate tool installed. You can install it with `brew install golang-migrate` (https://github.com/golang-migrate/migrate/tree/master/cmd/migrate)
3. To run any `make` command you should have `make` tool installed. You can install it with `sudo apt install make` command (https://linuxhint.com/install-make-ubuntu/)
4. Run `make migrate-up` command to run migrations and create all tables with test user (user_id: `63e83104-b9a7-4fec-929e-9d08cae3f9b9`)
5. Run `make run` command to run application
6. Take a look at `postman` folder to take collection for testing all endpoints

Test user with id `63e83104-b9a7-4fec-929e-9d08cae3f9b9` will be created automatically when you run migrations.
This user has 50 amount of his balance for testing.

## To run application in docker container:

1. Create `.env` file in root folder and add all required variables from `.env.example` file
2. To run docker container you should have `docker` and `docker-compose` tools installed (Tested on `Docker version 26.1.3, build b72abbb` and `Docker Compose version v2.27.1`)
3. `docker-compose up` - to run application in docker container
4. `docker-compose down` - to stop application in docker container
160 changes: 160 additions & 0 deletions subjects/devops/serverless/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,160 @@
## Serverless Payments Reminder

Serverless Payments Reminder is a basic Slack Bot that reminds companies / users to pay their bills. The reminder gets triggered by AWS EventBridge (also known as CloudWatch Events). The bot itself is hosted on a simple AWS Lambda function.

### Requirements for the task

Create a simple Slack bot using:

- [AWS](https://aws.amazon.com/)
- [Serverless Framework](https://serverless.com/)
- [Cloudformation](https://aws.amazon.com/cloudformation/)
- [Terraform](https://www.terraform.io/)

### Task

The task is separated into multiple different levels. The levels are ordered by complexity. You can choose the level that you feel most comfortable with.

## Level 0: Basic Lambda Function hosted via Serverless**

**1. Create Slack Bot**

Write a slack bot, that sends a reminder to slack channel with the following message:

```sh
Dear Board Members! This is a reminder to make the payment for the licenses of the software. The due date is 07.XX.YY, where XX is the month and YY is the year. The amount to be paid is $ZZZ.VV. Please make the payment as soon as possible to <IBAN_NUMBER>. Thank you!
```

The environment variables which must be available in the Lambda function are:

- `SLACK_WEBHOOK_URL` - The Slack Webhook URL
- `AMOUNT` - The amount to be paid
- `IBAN_NUMBER` - The IBAN number

The due date must be calculated based on the current date for the next month.

Before step two, you need to test that Slack Bot is functioning properly by running an application locally. It should send a message to the Slack channel.

**2. Write tests for the application**

Write integration tests for the application to ensure that each part of the application is functioning properly.

**3. Use [Serverless Framework](https://github.com/serverless/serverless) to host the lambda function**

Serverless framework is an automation tool used to deploy serverless applications which can help with event-driven architecture deployments.

Use the serverless framework to host the lambda function combined with AWS Eventbridge.

**Refs**

- [AWS EventBridge](https://www.serverless.com/framework/docs/providers/aws/events/event-bridge)
- [AWS Lambda Function](https://www.serverless.com/framework/docs/providers/aws/guide/functions).

AWS Eventbridge should trigger lambda function every month on the 1st day of the month at 10:00 AM.

**Note** Before hosting, you need to ensure that the bot is written in a way that it can be hosted on AWS Lambda. You can look at the example [here](https://github.com/KostLinux/aws-incident-manager-notifier/blob/56d52e90f8a14e689e7d2a1c7ee44590de5af2f5/main.go#L158).

## Level 1: Basic Lambda Function automation via Cloudformation**

**1. Repeat the 1st and 2nd step from Level 0**

Create a slack bot, that sends a reminder to slack channel. Write integration tests for the application to ensure that each part of the application is functioning properly.

**Note** Don't forget to add Lambda handler for the application

**2. Use [Cloudformation](https://aws.amazon.com/cloudformation/) to host the lambda function**

Cloudformation is Infrastructure As Code (IaC) tool used to automate the provisioning of AWS resources inside the AWS. It allows you to use a simple yaml syntax to define the resources you want to create.

**2.1 Hosting the Lambda function**

Write cloudformation template with parameters (variables) `SlackWebhookUrl`, `Amount`, `IbanNumber`. The template should automatically provision the Slackbot based on architecture mentioned in [Level 0](#level-0-basic-lambda-function-hosted-via-serverless) step 3.
zamazzal marked this conversation as resolved.
Show resolved Hide resolved

## Level 2: Basic Lambda Function automation via Basic Terraform with Local State**

Terraform is an Infrastructure As Code (IaC) tool used to automate the provisioning of resources inside different SaaS solutions and Cloud providers. It uses HCL syntax, which is easy maintainable. The main problem of terraform is that you need to know, how everything works under the hood (e.g. IAM roles, policies, serverless platforms etc).

**1. Repeat the 1st and 2nd step from Level 0**

Create a slack bot, that sends a reminder to slack channel. Write integration tests for the application to ensure that each part of the application is functioning properly.

**Note** Don't forget to add Lambda handler for the application

**2. Automate the hosting via Terraform**

**2.1 Write an IAM role with the least privilege principle for the lambda function and EventBridge.**

**2.2 Automatically pack up the lambda function into a zip file**

**2.3 Build the lambda function based on the zip file**

**2.4 Build AWS Eventbridge, which will trigger the lambda function**

**Note** Lambda function should be triggered every month on the 1st day of the month at 10:00 AM.

At this level you can use local state for terraform, no modules needed to write.

## Level 3: Basic Lambda Function automation via Terraform Module with Remote S3 State (advanced)**

In a DevOps world, mostly we use remote state for terraform. The main reason is that we can share the state with other team members and we can easily manage the state of the infrastructure. Although it is a bit more complex to set up, it allows you to avoid issues when someone even removes the state file, cause S3 has versioning turned on.

This level is more advanced, but more near to the real-world scenario. As a DevOps Engineer / SRE mostly all the terraform code is written in modules (or using community pre-built modules). Modules help us to maintain the codebase and reuse the code in different projects, so you don't need to write the same code again and again.

**1. Repeat the steps from [Level 2](#level-2-basic-lambda-function-automation-via-basic-terraform-with-local-state)**
zamazzal marked this conversation as resolved.
Show resolved Hide resolved

Repeat all the steps from Level 2, but now you need to write a terraform module for the lambda function and EventBridge. Which means that instead of writing values directly into main.tf file, everything should be written using variables. For example:

```tf
resource "aws_lambda_function" "slack_bot" {
function_name = var.function_name
role = var.role
handler = var.handler
runtime = var.runtime
timeout = var.timeout
}
```

We're using variables for each value, so we can reuse the module in different projects.

**2. Use remote state for terraform**

In this step you need to configure IAM User with least privilege principle for terraform to access S3 bucket, provision resources in Eventbridge and Lambda function.

**Note** We would recommend using [Cloudformation](https://aws.amazon.com/cloudformation/) to create an IAM User with the least privilege principle + S3 Bucket for the remote state. Cloudformation can be applied via AWS CLI which means that everything persists to be AS CODE.

**3. Use the S3 bucket for the remote state and module to provision the resources**

Write your backend configuration to backend.tf file:

```tf
terraform {
backend "s3" {
bucket = ""
key = ""
region = ""
encrypt = ""
}
}
```

Use the module written at step 1 to provision the resources

```tf
module "slack_bot" {
source = "./modules/slack_bot"
function_name = "slack_bot"
role = "arn:aws:iam::123456789012:role/lambda-role"
handler = "main.handler"
runtime = "nodejs14.x"
timeout = 10
}
```


## Helpful commands

- `serverless deploy` - Deploy the serverless application
- `aws cloudformation deploy --template-file template.yaml --stack-name my-stack` - Deploy the cloudformation stack
- `terraform init` - Initialize the terraform project and remote state.
- `terraform plan` - Plan the resources you're going to provision. It will show you the changes that will be made.
- `terraform apply` - Apply the terraform project only if you're sure that everything is correct during the plan.
Empty file.
Empty file.
3 changes: 3 additions & 0 deletions subjects/devops/serverless/main.tf
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
module "aws_slack_bot" {
source = "./modules/aws_slack_bot"
}
Empty file.
Empty file.