# How to Deploy a Next.js App on Vercel with GitHub Actions

## Introduction

Deploying a Next.js app on Vercel with GitHub Actions is a powerful way to streamline your development workflow. This guide will walk you through the process, ensuring your app is automatically deployed whenever changes are pushed to your GitHub repository.

## Prerequisites

- A Next.js application
- A GitHub repository containing your Next.js app
- A Vercel account

## Step 1: Set Up Your Next.js App on GitHub

Ensure your Next.js app is pushed to a GitHub repository. If you haven't done this yet, follow these steps:

1. Initialize a Git repository in your project folder: `git init`
2. Add your files: `git add .`
3. Commit your changes: `git commit -m "Initial commit"`
4. Create a new repository on GitHub
5. Push your code to GitHub: `git push -u origin main`

## Step 2: Connect Your Repository to Vercel

Next, we'll link your GitHub repository to Vercel:

1. Log in to your Vercel account
2. Click on "New Project"
3. Select your GitHub repository
4. Configure your project settings (Vercel should automatically detect that it's a Next.js app)
5. Click "Deploy"

## Step 3: Set Up GitHub Actions

Now, let's set up GitHub Actions to automate the deployment process:

1. In your GitHub repository, go to the "Actions" tab
2. Click on "New workflow"
3. Choose "Set up a workflow yourself"
4. Name your workflow file (e.g., `vercel-deploy.yml`)
5. Replace the content with the following YAML:
6. Or Create `.github/workflows/deploy.yml` file in your project folder

```yaml
name: Vercel Production Deployment
env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
  push:
    branches: [main]
jobs:
  Deploy-Production:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install Vercel CLI
        run: npm install --global vercel@latest
      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
      - name: Build Project Artifacts
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
      - name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}
```

## Step 4: Configure Vercel Token

To allow GitHub Actions to deploy to Vercel, you need to set up a Vercel token:

1. Go to your Vercel account settings
2. Navigate to "Tokens"
3. Create a new token and copy it
4. In your GitHub repository, go to "Settings" > "Secrets and variables" > "Actions"
5. Create a new repository secret named `VERCEL_TOKEN` and paste your Vercel token as the value

```jsx
{"orgId":"team_asdfaki890lj","projectId":"prj_B2olQkCg6b0CWV9GvzMsdfsdfUFEp6"}
```

## Step 5: Push Changes and Watch It Deploy

Now, whenever you push changes to the main branch of your GitHub repository, GitHub Actions will automatically trigger a deployment to Vercel.

## Conclusion

By following these steps, you've successfully set up automated deployments for your Next.js app using Vercel and GitHub Actions. This workflow will save you time and ensure that your production environment is always up to date with your latest code changes.

Remember to test your application thoroughly before pushing to the main branch, as changes will be automatically deployed to production. Happy coding!


Deploy a Next.js App on Vercel with GitHub Actions

# Semantic Versioning

Semantic versioning, known as `SemVer`, is a versioning system for software libraries, frameworks, and applications. It provides a standardized way of defining and communicating changes to software versions in a clear and predictable manner. It uses a three-part version separated by dots i.e. `MAJOR.MINOR.PATCH` → `1.4.2`. These numbers represent different levels of changes made to the software.

![SemVer](https://aanay.pythonanywhere.com/media/default/semver.png)

`MAJOR`, is incremented when there are major changes to the software that are not backward compatible. This could include changes to the API, major feature additions, or restructuring of the codebase.

```bash
npm version major
```

`MINOR`, is incremented when there are minor changes to the software that are backward compatible. This could include the addition of new features or functionality, bug fixes, or small improvements.

```bash
npm version minor
```

`PATCH`, is incremented when there are minor changes to the software that is backward compatible and do not add any new features. This could include bug fixes or minor improvements.

```bash
npm version patch
```

Semantic Versioning also allows for the use of pre-release version numbers and build metadata. Pre-release version numbers are indicated by appending a hyphen and a series of alphanumeric characters to the end of the version number. Build metadata is indicated by appending a plus sign and a series of alphanumeric characters to the end of the version number.

| Code Status                               | Stage         | Rule                                                               | Example version |
| ----------------------------------------- | ------------- | ------------------------------------------------------------------ | --------------- |
| First release                             | New product   | Start with 1.0.0                                                   | 1.0.0           |
| Backward compatible bug fixes             | Patch release | Increment the third digit                                          | 1.0.1           |
| Backward compatible new features          | Minor release | Increment the middle digit and reset last digit to zero            | 1.1.0           |
| Changes that break backward compatibility | Major release | Increment the first digit and reset the middle and last digits to zero | 2.0.0           |

[About semantic versioning | npm Docs](https://docs.npmjs.com/about-semantic-versioning)

![Sign](https://aanay.pythonanywhere.com/media/default/sign.png)

With the help of the Semantic Versioning system, developers and users can more easily grasp the effects of updates and upgrades by communicating changes to software versions in a clear and concise manner. Additionally, it minimizes the chance of compatibility issues by ensuring that various software components can function together seamlessly.

## Thank You 😁😁😁


Understanding Semantic Versioning

## Installation via [Docker](https://docs.docker.com/get-docker/)

Run the following commands in your terminal

```bash
docker --version # check version 

docker pull jenkins/jenkins:lts # pull jenkins latest version

docker images # list docker images

docker run --detach --publish 8090:8080 --volume jenkins_home:/var/jenkins_home --name jenkins jenkins/jenkins:lts # runs on localhost:8090

docker run -u 0 -d --net=host -v  /home/jenkins/home:/var/jenkins_home -v  /home/jenkins/root:/root jenkins/jenkins # optional
```

## Using the Initial Admin Password

Run the following command and copy the initial password (output on the terminal):

```bash
docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword # get inital admin password
```

Open a browser to [localhost:8080](http://localhost:8080) and enter the initial admin password.

<hr />

### Project or Job

- A user-configured description of the work that Jenkins will manage

### Build

- One run of a project

### Build Step

- A task inside a project

### Build Trigger

- Criteria for starting a bulid
- Can be manual of automatic

### Plugins

- A software package that extends Jenkins' core functionality


Jenkins Setup with Docker

> Git is a free and *open-source* distributed *Version Control System* (VCS) design to handle everything from small to large project with speed and efficiency.

> Github is a collaboration platform built on top of git

To get started with Git download git from [https://git-scm.com/](https://git-scm.com/)

## Configuring Git

```bash
git config --system 
git config --global
git config --local
```

## Configure user name email for git

```bash
git config --global user.name "<username>"
git config --global user.email "<useremail>"
git config --global core.editor "atom --wait"
git config --global color.ui true
git config --list
```

## Let's write some git commands

| Command                              | Explanation                              |
| :----------------------------------- | :--------------------------------------- |
| `$ git init`                         | Initialize git in your directory         |
| `$ git add <filename>`               | Add changes to the staging index         |
| `$ git commit -m "<Commit message>"` | Commit the changes to the git repository |

- Commit Message
- A short -single summary (less than 50 characters)
- Good if the commit is in present tense

| Command                             | Explanation                                                  |
| :---------------------------------- | :----------------------------------------------------------- |
| `git clone <url>`                   | Git clone is used to clone a remote repository into a local workspace |
| `git push`                          | Git push is used to push commits from your local repo to a remote repo |
| git pull                            | Git pull is used for fetch the newest updates from a remote repository |
| `$ git branch`                      | Used to manage branches                                      |
| `$ git branch <branch name>`        | Creates the branch                                           |
| `$ git branch -d "<branch name>"`   | Deletes the branch                                           |
| `$ git branch -D "<branch name>"`   | Forcibly deletes the branch                                  |
| `$ git checkout "<branch name>"`    | Switches to a branch                                         |
| `$ git checkout -b "<branch name>"` | Creates a new branch and switches to it.                     |
| `$ git merge "<branch name>"`       | Merge joins branches together                                |
| `$ git merge -abort`                | If there are merge conflicts (meaning files are incompatible). --abort can be used to abort the merge action |
| `$ git log --graph --oneline`       | This shows a summarize view of the commit history for a repository. |

## Show the difference in the tracked files

| Command                  | Explanation                                                  |
| :----------------------- | :----------------------------------------------------------- |
| `git show`               | git show is used to show the changes in the head of master commit |
| `git diff`               | git diff is used to show the difference in the untracked files |
| git diff staged          | git diff is used to show the difference in the tracked files |
| `$ git diff <commit ID>` | show difference in the commit                                |
| git clone URL            | Git clone is used to cone a remote repository into a local workspace |
| git push                 | Git push is used to push commits from your local repo to a remote repo |
| git pull                 | Git pull is used to fetch the newest updates from a remote repository |
| git remote               | Lists remote repos                                           |
| git remote -v            | List remote repos verbosely                                  |
| git remote show `<name>`   | Describes a single remote repo                               |
| git remote update        | Fetches the most up-to-date objects                          |
| git fetch                | Downloads specific objects                                   |
| git branch -f            | Lists remote branches: can be combined with other branch arguments to manage remote branches |
| git log -p               | Produces patch text                                          |
| git add -p               | Allows a user to interactively review patches to add to the current  commit |
| git mv                   | Similar to the  Linux 'mv' command, this moves a file        |
| git rm                   | Similarly to the Linux 'rm' command, this deletes, or removes a file |

# push existing repository from the command line
```bash
git remote add origin https://github.com/NepOrganics/nep-org-dashboard.git
git branch -M main
git push -u origin main
```

## Thank You 😁😁😁

Git and GitHub

# Continue on Docker and Docker-Compose

```bash
docker ps -l --format=$FORMAT
docker tag docker_id image_name # name the containers

docker commit test test1
docker run --rm -ti ubuntu sleep 5 ## remove after exit (terminal interactive)
docker run -ti ubuntu bash -c "sleep 3; echo all done"

docker run -d -ti ubuntu bash # d -> detach
```

## Running things running in a container

`docker attach`

- detached containers
- interactive containers
- detach with Control-p control-q
- docker ps
- docker attach *container_name*

## Running more things in a container

`docker exec`

- Starts another process in an existing container
- great for debugging and DB administration
- can't add ports, volumes, and so on

## Looking at container output

`docker logs`

- keep the output of containers
- View with `docker logs container_name`
- `docker run --name example -d ubuntu bash -c "lose /etc/password"` (--name to name the container to example and detach to run in the background, give process bash)
- don't let the output get too large

## Stopping and removing containers

- killing and removing containers
- `docker kill container_name` (stop container)
- `docker rm container_name` (remove the container)
- `docker ps -l` (last container to exit)

## Resource constraints

- memory limits
    - `docker run --memory maximum-allowed-memory-image-name command`
- CPU Limits
    - `docker run --cpu-shares` relative to other containers
    - `docker run --cpu-quota` to limit it in general
- Orchestration
    - Generally requires resource limiting

## Lessons from the field

- Don't let your containers fetch dependencies when they start
- Don't leave important things in unnamed stopped containers

## Container Networking

- Programs in containers are isolated from the internet by default
- You can group your containers into "private" networks
- You explicitly choose who can connect to whom
- expose ports to let connections in
- Private networks to connect between containers

## Exposing specific ports

- Explicitly specifies the port inside the container and outside
- Exposes as many ports as you want
- Requires coordination between containers
- Makes it easy to find the exposed ports
- `docker run --rm -ti -p 45678:45678 -p 45679:45679 --name echo-server ubuntu:14.04 bash` (publish 45678 to 45678)
    - `nc -lp 45678 | nc -lp 45679`
    - `nc localhost 45678`
    - `nc localhost 45679`
    - `docker run --rm -ti ubuntu:14.04`
    - `nc host.docker.internal 45678` (inside the running container) (put the ip address for windows for `host.docker.internal`)

## Exposing Ports Dynamically

- The port inside the container is fixed
- The port on the host is chosen from the unused ports
- This allows many containers to run programs with fixed ports
- This often is used with a service discovery program
- without port `docker run --rm -ti -p 45678 -p 45679 --name echo-server ubuntu:14.04 bash`
- `docker port echo-server`

## Exposing UDP Ports

- `docker run -p outside-port:inside-port/protocol (tcp/udp)`
- `docker run -p 1234:1234/upd`
- `docker run --rm -ti -p 45678/udp --name echo-server ubuntu:14.04 bash`
- `nc -ulp 45678`
- `docker port echo-server`
- `docker run --rm -ti ubuntu:14.04 bash`
- `nc -u host.docker.internal 34545`

## Container Networking

- `docker network ls`
- `docker network create learning` create a network
- `docker run --rm -ti --net learning --name catserver ubuntu:14.04 bash`
    - `ping catserver`
- `docker run --rm -ti --net learning --name dogserver ubuntu:14.04 bash`
    - `nc -lp 1234`
    - on catserver container `nc dogserver 1234`
- `docker network create catsonly`
- `docker network connect catsonly catserver`
- `docker run --rm -ti --net catsonly --name bobcatserver ubuntu:14.04 bash`

## Legacy Linking

- Links all ports, though only one way
- Secret environment variables are shared only one way
- Depends on the startup order
- Restarts only sometimes breaks the links
- `docker run --rm -ti -e SECRET=theinternetlovescat --name catserver ubuntu:14.04 bash`
- `docker run --rm -ti --link catserver --name dogserver ubuntu:14.04 bash`
    - `nc -lp 4321`
    - `nc dogserver 4321`
    - `nc catserver 4321`
    - `env`

## Images

### Tagging Images

- Tagging gives images names
- `docker commit` tags images for you
- `docker commit container_id name_yo_like_to_give`
- `docker commit ea4fd18fc19d my-image:v2.1`
- This is an example of the name structure:
    - `registry.example.com:port/organ-ization/image-name:version-tag`
- You can leave out the parts you don't need
- `Organization/image-name` is often enough
- `docker pull`
- Run automatically by `docker run`
- Useful for offline work
- Opposite `docker push`

## Cleaning UP

- Images can accumulate quickly
    - docker rmi image-name:tag
    - docker rmi image-id

## Volumes

- Shared folder
- Virtual 'discs' to store and share data
- Two main varieties
    - Persistent (data will be still there after the container is away)
    - Ephemeral (temporary, no container is not using them it goes away)
- Not part of images

### Sharing Data with the host

- "Shared folders" with the host
- Sharing a "single file" into a container
- Note that a file must exist before you start the container, or it will be assumed to be a directory
- `docker run -ti -v D:\\Projects\\example:/shared-folder ubuntu bash`

### Sharing data between containers

- volumes-from
- Shared "discs" that exist only as long as they are being used
- Can be shared between containers
- `docker run -ti -v /shared-data ubuntu bash`
- `docker run -ti --volumes-from nervous_galois ubuntu bash`

## Docker Registries

- Registries manage and distribute images
- Docker (the company) offers these for free
- You can run your own, as well

### Finding images

- Docker `search` commands
- docker pull debian:sid
- docker tag debian:sid prakashpun7/test-image:v99.9
- docker push prakashpun7/test-image:v99.9
- Clean up your images regularly

## What is a Dockerfile

- This is a small "program" to create an image
- You run this program with
    - docker build -t name-of-result . Note that. here (where to search for Dockerfile)
- When it finishes, the result will be in your local docker registry

### Producing the Next Image with Each Step

- Each line takes the image from the previous line and makes another image
- The previous image is unchanged
- It does not edit the state from the previous line
- You don't want large files to span lines or your image will be huge

### Caching with each step

- This is important; watch the build output for "using cache"
- Docker skips lines that have not changed since the last build
- If your first line is "download the latest file", it may not always run
- This caching saves huge amounts of time
- The parts that change the most belong at the end of the Dockerfile

### Dockerfile are not Shell Scripts

- Dockerfiles look like shell scripts
- Dockerfiles are not shell scripts
- processes you start on one line will not be running on the next line
- Environment variables you set will be set on the next line
    - if you use the ENV command, remember that each line is its own call to docker run

```bash
# FROM debian:sid
# RUN apt-get -y update
# RUN apt-get -y install nano
# CMD ["bin/nano", "/tmp/notes"]
FROM example/nanoer
ADD notes.txt /notes.txt
CMD ["bin/nano", "/notes.txt"]

```

### The FROM Statement

- Which image to download and start from
- Must be the first command in your Dockerfile
    - FROM java:8

### The MAINTAINER Statement

- Defines the author of this Dockerfile
    - MAINTAINER Firstname Lastname [email@example.com](mailto:email@example.com)

### The RUN Statement

- Runs the comand line, waits for it to finish, and saves the result
    - `RUN unzip install.zip /opt/install/`
    - `RUN echo Hello`

### The ADD Statement

- Adds local files
    - Add [run.sh](http://run.sh/) /run.sh
- Add the contents of tar archives
    - ADD project.tar.gz /install/
- Works with URLs as well
- `ADD <https://project.example.com/download> /1.0/project.rpm /project/`

### The ENV Statement

- Sets environment variables
- Both during the build and when running the result
    - ENV DB_HOSt=[db.production.example.com](http://db.production.example.com/)
    - ENV DB_PORT=5432

### The ENTRYPOINT and CMD Statements

- ENTRYPOINT specifies the start of the command to run
- CMD specifies the whole command to run
- If you have both ENTRYPOINT and CMD, they are combined together
- If your container acts like a command-line program, you can use ENTRYPOINT
- If you are unsure, you can use CMD

### Shell From vs.Exec From

- ENTRYPOINT RUN and CMD can use either form.
- Shell form looks like this:
    - nano notes.txt
- Exec form looks like this:
    - ["/bin/nano", "notes.txt"]

### The EXPOSE Statement

- Maps a port into the container
    - EXPOSE 8080

### The VOLUME Statment

- Defines shared or ephemeral volumes
    - VOLUME ["/host/path/", "/container/path/"]
    - VOLUME ["/shared-data"]
- Avoid defining shared folders in DockerFiles

### The WORKDIR Statement

- Sets the directory the container starts in
    - WORKDIR /install/

### The USER Statment

- Sets which user the container will run as
    - USER arthur
    - USER 100

## Multi-project Docker files

- `docker build -t google-size .`

```
FROM ubuntu:16.04
RUN apt-get update
RUN apt-get -y install curl
RUN curl <https://google.com> | wc -c > google-size
ENTRYPOINT echo google is this big; cat google-size
```

```
FROM ubuntu:16.04 as builder
RUN apt-get update
RUN apt-get -y install curl
RUN curl <https://google.com> | wc -c > google-size

FROM alpine
COPY --from=builder /google-size /google-size

ENTRYPOINT echo google is this big; cat google-size

```

### Preventing the Golder Image Problem

- Include installers in your project
- Have a canonical build that builds everything completely from scratch
- Tag your builds with the git hash of the code that build it
- Use small images, such as Alpine
- Build images you shae publicly from Dockerfiles, always
- Don't ever leave passwords in layers; delete files inthe same step!

## What Kernels Do

- Respond to message from the hardware
- Start and schedule programs
- Control and organize storage
- Pass messages between programs
- Allocate resources, memory, CPU, network, and so on.
- Create containers by Docker configuring the kernel

## What Docker does

- Program is written in Go -- upcoming systems language
- Manages kernel features
    - Uses "cgroups" to contain process
    - Uses "namespaces" to contain networks
    - Uses "copy-on-wirte" filesystems to build images

## What Docker Really Does

- Makes scripting distributed systems "easy"*
    - For a very peculiar definition of "easy"

## The Docker Control Socket

- Docker is two programs: a client and a server
- The server receives commands over a socket (either over a network or through a "file")
- The client can even run inside the docker itself

## Networking in Brief

- Ethernet: moves "frames" on a wire (or Wi-Fi)
- IP layer: moves packets on a local network
- Routing: forwards packets between networks
- Ports: address particular programs on a computer

## Bridging

- Docker uses bridges to create virtual networks in your computer
- These are software switches
- They control the Ethernet layer
- `docker run -ti --rm --net=host ubuntu:16.04 bash`
- `apt-get update && apt-get install bridge-utils`
- `brctl show`
- `docker network create my-network`
- You can turn off this protection with
    - docker run --net=host options image-name command

## Routing

- Creates "firewall" rules to move packets between networks
- NAT (Network Address Translation)
- Change the source address on the way out
- Change the destination address on the way back in
- `docker run -ti --rm --net=host --privileged=true ubuntu bash`
- `apt-get update && apt-get install iptables`
- `iptables -n -L -t nat`
- "Exposing" a port --really "Port forwarding"

## Namespaces

- They allow processes to be attached to private network segments
- These private networks are bridged into a shared network with the rest of the containers
- Containers have virtual network "cards"
- Containers get their own copy of the networking stack

## Primer on Linux Processes

- Processes come from other processes--parent-child relationship
- When a child process exits, it returns an exit code to its parent
- Process Zero is special; called *init*, the process that starts the rest
- In Docker, your container starts with an init process and vanishes when that process exits
- `docker inspect --format '{{.State.Pid}}' container-name`
- `kill 7538` => 7538 = pid

## Resource Limiting

- Scheduling CPU time
- Memory allocation limits
- Inherited limitations and quotas
- Can't escape your limits by starting more process

## Unix Storage in Brief

- Actual storage devices
- Logical storage devices
- Filesystems
- FUSE filesystems and network filesystems
- COW;s => copy on write

### Moving Cows

- The contents of layers are moved between containers in gzip files
- Containers are independent of the storage engine
- Any containers can be loaded (almost) anywhere
- It is possible to run out of layers on some of the storage engines

### Volumes and Bind Mounting

- The Linux VFS (Virtual File System)
- Mounting devices on the VFS
- Mounting directories on the VFS
- `mount -o bind other-work work`
- Getting the mount order correct
- Mounting volumes --always mounts the host's filesystem over the guest

## What is a Docker Registry?

- Maintains an index and searches tags
- Authorizes and authenticates connections (sometimes)
- `docker save -o my-images.tar.gz debian:sid busybox ubuntu:14.04`
- `docker rmi debian:sid busybox ubuntu:14.04`
- `docker load -i my-images.tar.gz`

## Saving and Loading Containers

- docker save
- docker load
- Migrating between storage types
- Shipping images on disks (or never underestimate the bandwidth of a thumb drive in a get liner)

## Intro to orchestration (One Container = One Hand Clapping)

- Many orchestration systems of Docker
- Start containers--and restart them if they fail
- Service discovery--allow them to find each other
- Resource allocation--match containers to computers

## Docker Compose

- Single machine coordination
- Designed for testing and development
- Brings up all your containers, volumes, networks, etc., with one command

## Kubernetes

- Containers run programs
- Pods group containers together
- Services make pods available to others.
- Labels are used for very advanced service discovery

### Advantages of Kubernetes

- Make scripting large operations possible with the `*kubect1*` command
- Very flexible overlay networking
- Runs equally well on your hardware or a cloud provider
- Built-in service discovery
- Get started at http://kubernetes.io/

## EC2 Container Service (ECS)

- Task definitions
    - Define a set of containers that always run together
- Tasks
    - Actually makes a container run right now
- Services and exposes it to the Net
    - Ensures that a task is running all the time

## Advantages of ECS

- Connects load balancers (ELBs) to services
- Can create your own host instances in AWS
- Make your instances start the agent and join the cluster
- Pass the docker control socket into the agent
- Provides docker repos--and it's easy to run your own repo
- Note that containers (tasks) can be part of CloudFormation stacks!
- Get started at https://aws.amazon.com/ecs/

```
FROM node:12
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
ENV PORT=4000
EXPOSE 4000
CMD ["npm", "start"]
```

`docker build -t prakashpun/demoapp:1.0 .` `docker run -p 5000:4000 container_id`

```jsx
=> docker file 
=> blueprint for building docker image image 
=> template for running docker container container 
=> running process
```

## Thank You 😁😁😁

Docker and Docker-Compose Advanced

📖[Read More on Why Docker](https://www.docker.com/why-docker)

- Docker Compose is a tool that was developed to help define and share multiple-container applications. With Compose, we can create a YAML file to define the services, and with a single command, can spine everything up or tear it all down.
- The big advantage of using Compose is you can define your application stack in a file, keep it in a file, keep it at the root of your project repo (it’s now version controlled), and easily enable someone else to contribute to your project. Someone would only need to clone your repo and start the compose app. In fact, you might see quite a few projects on GitHub/GitLab doing exactly this now.

## Installing Docker Compose

If you installed Docker Desktop/Toolbox for either Windows or Mac, you already have Docker Compose! Play-with-Docker instances already has Docker Compose installed as well. If you are in a Linux machine, you will need to install Docker Compose using CLI

After installation, you should be able to run the following and see version information.

```docker
docker-compose version
```

## Creating a Compose File

1. At the root of the app project, create a file named `docker-compose.yaml`.
2. In the compose file, we'll start off by defining the schema version. In most cases, it's best to use the latest supported version. You can look at the Compose reference for the current schema versions and the compatibility matrix.

    ```docker
    version: "3.8"
    ```

3. Next, we'll define the list of services (or containers) we want to run as part of our application.

    ```docker
    version: "3.8"
    
    services:
    ```

And now, we'll start migrating a service at a time into composing file.

## Defining the App Service

To remember, this was the command we were using to define our app container.

```bash
docker run -dp 3000:3000 \
 -w /app -v "$(pwd):/app" \
 --network todo-app \
 -e MYSQL_HOST=mysql \
 -e MYSQL_USER=root \
 -e MYSQL_PASSWORD=secret \
 -e MYSQL_DB=todos \
 node:12-alpine \
 sh -c "yarn install && yarn run dev"
```

If you are using PowerShell then use this command.

```bash
docker run -dp 3000:3000 `
 -w /app -v "$(pwd):/app" `
 --network todo-app `
 -e MYSQL_HOST=mysql `
 -e MYSQL_USER=root `
 -e MYSQL_PASSWORD=secret `
 -e MYSQL_DB=todos `
 node:12-alpine `
 sh -c "yarn install && yarn run dev"
```

1. First, let's define the service entry and the image for the container. We can pick any name for the service. The name will automatically become a network alias, which will be useful when defining our MySQL service.

    ```docker
    version: "3.7"
    
    services:
     app:
      image: node:12-alpine
    ```

2. Typically, you will see the command close to the image definition, although there is no requirement for ordering. So, let's go ahead and move that into our file.

    ```docker
    version: "3.7"
    
    services:
     app:
      image: node:12-alpine
      command:sh -c "yarn install && yarn run dev"
    ```

3. Let's migrate the `p 3000:3000` part of the command by defining the ports for the service. We will use the short syntax here, but there is also a more verbose long syntax available as well.

    ```docker
    version: "3.7"
    
    services:
     app:
      image: node:12-alpine
      command:sh -c "yarn install && yarn run dev"
      ports:
        - 3000:3000
    ```

4. Next, we'll migrate both the working directory (`w /app`) and the volume mapping (`v "$(pwd):/app"`) by using the `working_dir` and `volumes` definitions. Volumes also has short and long syntax.

    One advantage of docker Compose volume definitions is we can use relative paths from the current directory.

    ```docker
    version: "3.7"
    
    services:
     app:
      image: node:12-alpine
      command:sh -c "yarn install && yarn run dev"
      ports:
        - 3000:3000
      working_dir: /app
      volumes:
        - ./:/app
    ```

5. Finally, we need to migrate environment variable definitions using the `environment` key.

    ```docker
    version: "3.7"
    
    services:
     app:
      image: node:12-alpine
      command:sh -c "yarn install && yarn run dev"
      ports:
        - 3000:3000
      working_dir: /app
      volumes:
        - ./:/app
      environment:
        MYSQL_HOST=mysql
               MYSQL_USER=root
               MYSQL_PASSWORD=secret
               MYSQL_DB=todos
    ```

## Defining the MySQL Service

Now, it's time to define the MySQL service. The command that we used for that container was the following:

```docker
docker run -d \
 --network todo-app --network-alias mysql \
 -v todo-mysql-data:/var/lib/mysql \
 -e MYSQL_ROOT_PASSWORD=secret \
 -e MYSQL_DATABASE=todos \
 mysql:5.7
```

If you are using PowerShell then use this command.

```docker
docker run -d `
 --network todo-app --network-alias mysql `
 -v todo-mysql-data:/var/lib/mysql `
 -e MYSQL_ROOT_PASSWORD=secret `
 -e MYSQL_DATABASE=todos `
 mysql:5.7
```

1. We will first define the new service and name it MySQL so it automatically gets the network alias. We'll go ahead and specify the image to use as well.

    ```docker
    version: "3.7"
    
    services:
     app:
     # The app service defination
     mysql:
        image: mysql:5.7
    ```

2. Next, we'll define volume mapping. When we ran the container with `docker run` , the named volume was created automatically. However, that doesn't happen when running with Compose. We need to define the volume in the top-level `volumes:` section and then specify the mountpoint in the service config. By simply providing only the volume name, the default options are used. There are many more options available though.

    ```docker
    version: "3.7"
    
    services:
     app:
     # The app service defination
     mysql:
        image: mysql:5.7
     volumes:
        - todo-mysql-data:/var/lib/mysql
    volumes:
     todo-mysql-data:
    ```

3. Finally, we only need to specify the environment variables.

    ```docker
    version: "3.7"
    
    services:
     app:
     # The app service defination
     mysql:
        image: mysql:5.7
     volumes:
        - todo-mysql-data:/var/lib/mysql
     environment:
        MYSQL_ROOT_PASSWORD: secret
        MYSQL_DATABASE: todos
    volumes:
     todo-mysql-data:
    ```

At this point, our complete `docker-compose.yaml` should look like this:

```Dockerfile:docker-compose.yaml
version: "3.7"

services:
 app:
  image: node:12-alpine
  command:sh -c "yarn install && yarn run dev"
  ports:
    - 3000:3000
  working_dir: /app
  volumes:
    - ./:/app
  environment:
    MYSQL_HOST=mysql
           MYSQL_USER=root
           MYSQL_PASSWORD=secret
           MYSQL_DB=todos
  mysql:
    image: mysql:5.7
        volumes:
           - todo-mysql-data:/var/lib/mysql
        environment:
           MYSQL_ROOT_PASSWORD: secret
           MYSQL_DATABASE: todos
volumes:
 todo-mysql-data:
```

## Running our Application Stack

Now that we have our `docker-compose.yaml` file, we can start it up!

```bash
docker-compose up --build -d
```

Add `-d` flag to run everything in the background.

```bash
docker-compose logs -f
```

The `-f` flag "follows" the log, so will give you live output as it's generated

```docker
docker-compose logs -f app
```

## Thank You 😁😁😁

Docker Compose

## About Docker?

- A program that builds container from code.
- A service that distributes container.
- Code and dependencies are packaged together, so software runs more reliably in different environments.
- Container are lightweight in comparison to virtual machines.

## What docker does?

- Craves up a computer into sealed container that runs your code.
- Gets the code to and from your computers.
- Builds these container for you.
- Social platform for you to find and share containers which are different from virtual machines.

### What is a container?

A container is simply another process on your machine that has been isolated from all over process on the host machine.

- Sealed, Self-contained units of software that have everything needed to run a service or code
- A container include: Code, Configs, Processes, Networking, Dependencies, Operating System

```bash
> docker run -d -p 80:80 docker/getting-started
[-d] run the container in the detached mode
[-p 80:80] map port 80 of the host to port 80 in the container
[docker/getting-started] the image to use
> docker run -dp 80:80 docker/getting-started
> docker build -t getting-started .
> docker run -dp 3000:3000 getting-started
```

### What is Container Image?

When running a container. It uses an isolated filesystem. This custom filesystem is provided by a container image. Since, the image contains the container's filesystem, it must contains everything needed to run an application - all dependencies, configuration, scripts, binaries etc. The image also contains, other configuration for the container, such as environment variables, a default command to run and other metadata.

### Docker File

It is a simply a text-based script of instructions that is used to crate a container image.

## Commands

```bash
> docker ps [get the id of the container]
> docker stop <container-id> [to stop the container]
> docker rm <container-id> [remove container once the container has stopped]
```

### Pushing our image

```bash
> docker push docker/getting-started
> docker login -u <username> [login to the docker hub]
> docker tage getting-started YOUR-NAME/getting-started [to give the geeting-started image a new name]
> docker push user-name/getting-started
> dokder run -dp 3000:3000 YOUR-NAME/getting-started [run the current pushed]
```

### More Commands

```bash
> docker logs -f <continer-id>
> docker-compose logs
> docker exec -it <container-id> mysql -p
> docker-compose exec -it <container-name> sh
> docker run -ti ubuntu:latest bash [terminal interactive]
> docker ps
> docker ps --format $FORMAT
> docker container run -d --name=mypostgres -p 5432:5432 -e POSTGRES_PASSWORD=prakashpun -e PGDATA=/pgdata -v /pgdata:/pgdata postgres
> docker container exec -it pg psql -U postgres
> docker run --name myredis -d redis
```

![Image.png](https://i.imgur.com/WnAsfyI.png)

<p>
  Docker vs Virtual Machine [Docker](https://www.docker.com/)
</p>

| **Docker**                                                      | **Virtual Machine**                                                                      |
| --------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Application Layer abstraction                                   | Physical layer abstraction                                                               |
| Consume less space than VMs                                     | Include a full copy of the operating system                                              |
| Fast to startup                                                 | Boot up slowly                                                                           |
| Shared OS kernel allows many containers to run on a single host | Multiple virtual machines run on one server at a greater resource cost per guest machine |

## Dockerfiles, Images, and Container

Before moving forward with the workflow file, let's spend some time on these concepts. There are important differences between *Dockerfiles*, *Images*, and *Containers*.

| **Dockerfile**                                                                                   | **Docker Image**                                                                                                                                                       | **Docker Container**                                                                          |
| ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| Text document that contains all the commands and instructions necessary to build a Docker Image. | Executable packages comprised of code, dependencies, libraries, a runtime, environment variables, and configuration files. Very similar to a virtual machine snapshot. | A runtime instance of a Docker Image. This is what the image becomes when executed in memory. |

## Thank You 😀😀

Docker

## Setup ESLint, Prettier, and Husky in Next.js Typescript project

### Initiating the project

Create the next app with `create next-app` and navigate to the project directory and open vscode `code .`
```bash
yarn create next-app --typescript
cd test-app
code .
```

## Configure Eslint 
By default, eslint is installed by default. So, you can run eslint with the following command
```
yarn eslint .
```

To have a nice set of eslint rules, I suggest you install the package `@typescript-eslint/eslint-plugin`:
```
yarn add --dev @typescript-eslint/eslint-plugin
```
```json:.eslintrc.json
{
  "plugins": ["@typescript-eslint"],
  "extends": [
    "next/core-web-vitals",
    "plugin:@typescript-eslint/recommended"
  ],
  "rules": {
    // I suggest you add those two rules:
    "@typescript-eslint/no-unused-vars": "error",
    "@typescript-eslint/no-explicit-any": "error"
  }
}
```

## Configure Prettier
Now that we have eslint up and running, let's add auto-formatting with Prettier.

First, add prettier dependencies:

```
yarn add --dev prettier eslint-config-prettier
```

`eslint-config-prettier` will prevent conflicts between prettier and eslint rules.
Create a `.prettierrc.json` file, and configure it according to your preferences.
```json:.prettierrc.json
{
  "semi": false,
  "trailingComma": "es5",
  "singleQuote": true,
  "tabWidth": 2,
  "useTabs": false
}
```

Update `.eslintrc.json`
```json:.eslintrc.json
{
  // ...
  "extends": [
    "next/core-web-vitals",
    "plugin:@typescript-eslint/recommended",
    "prettier" // Add "prettier" last. This will turn off eslint rules conflicting with prettier. This is not what will format our code.
  ],
  // ...
}
```

##  Husky: Checking for errors, linting, and formatting on the commit

Husky, a little program that will run scripts for a given Git command.

## Install Husky
```
yarn add --dev husky
```
*You then need to enable husky by running:**

`yarn husky install`
⚠️ In the future, after you or someone else clone the project, you will need to run `yarn husky install` to enable husky

Now we need to add the git hook:

```
yarn husky add .husky/pre-commit "yarn tsc --noEmit && yarn eslint . && yarn prettier --write ."
```

Note: If you want to skip the check, you can add a `--no-verify` flag to your commit command. For example `git commit --no-verify -m "Update README.md"`

## Install lint-staged
```
yarn add --dev lint-staged
```
## Configure lint-staged
Create a configuration lint-staged.config.js file for lint-staged.
```javascript:lint-staged.config.js
module.exports = {
  // Type check TypeScript files
  '**/*.(ts|tsx)': () => 'yarn tsc --noEmit',

  // Lint then format TypeScript and JavaScript files
  '**/*.(ts|tsx|js)': (filenames) => [
    `yarn eslint --fix ${filenames.join(' ')}`,
    `yarn prettier --write ${filenames.join(' ')}`,
  ],

  // Format MarkDown and JSON
  '**/*.(md|json)': (filenames) =>
    `yarn prettier --write ${filenames.join(' ')}`,
}
```

Now we need to change our pre-commit hook (in the `.husky/pre-commit file`):
```sh:.husky/pre-commit
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

yarn lint-staged # 
```
### Thank You 👏