Forem: Gino Osahon

Getting Started with AWS Containers Part Two

Gino Osahon — Wed, 12 Jul 2023 12:21:40 +0000

Overview

Welcome to part 2 of my blog post on getting started with AWS Containers. In part 2, You will learn about the following concepts. Setting up AWS for Containers, Building and Packaging Containerized Applications, Setting Up Docker on AWS, Deploying ECS containers. Not to worry, if these terms are new to you — you'll learn about them here!

You will learn about the following topics in this second part of the blog post.

Setting Up AWS for Containers
- Creating an AWS account
- Configuring AWS Identity and Access Management (IAM) roles and policies
- Creating a VPC with Public and Private Subnets for Your Clusters
Building and Packaging Containerized Applications
- Choosing a containerization technology (Docker, containerd, etc.)
- Introduction to Docker
- Setting Up Docker on AWS
- How to deploy and manage Docker containers on AWS EC2

Prerequisites

To follow this tutorial, you are strongly advised to read article one here

1. Setting Up AWS for Containers

Creating an AWS Account

Watch this YouTube video created by Cloud Tech on how to create an AWS account :

Configuring AWS Identity and Access Management (IAM) Roles and Policies

Watch this YouTube video created by Inquirinity on how to configure IAM for an AWS account :

You can also visit Amazon Webservice documentation website to learn all about IAM on AWS

Creating a VPC with Public and Private Subnets for Your Clusters

Container instances in your clusters need external network access to communicate with the Amazon ECS service endpoint. However, you might have tasks and services that you would like to run in private subnets. Creating a VPC with both public and private subnets provides you the flexibility to launch tasks and services in either a public or private subnet. Tasks and services in the private subnets can access the internet through a NAT gateway. Services in both the public and private subnets can be configured to use a load balancer so that they can still be reached from the public internet.

This tutorial guides you through creating a VPC with two public subnets and two private subnets, which are provided with internet access through a NAT gateway.

Step 1: Create an Elastic IP Address for Your NAT Gateway

A NAT gateway requires an Elastic IP address in your public subnet, but the VPC wizard does not create one for you. Create the Elastic IP address before running the VPC wizard.

To create an Elastic IP address, open the Amazon VPC console or visit this URL https://console.aws.amazon.com/vpc/ and sign in. Follow the below steps:

In the left navigation pane, choose Elastic IPs.
Choose Allocate new address, Allocate, Close.

Note the Allocation ID for your newly created Elastic IP address; you enter this later in the VPC wizard.

Step 2: Run the VPC Wizard

The VPC wizard automatically creates and configures most of your VPC resources for you.
To run the VPC wizard, in the left navigation pane, choose VPC Dashboard.
Choose Launch VPC Wizard, VPC with Public and Private Subnets, Select.
For VPC name, give your VPC a unique name.
For Elastic IP Allocation ID, choose the ID of the Elastic IP address that you created earlier.
Choose Create VPC.

When the wizard is finished, choose OK. Note the Availability Zone in which your VPC subnets were created. Your additional subnets should be created in a different Availability Zone.

Non-default subnets, such as those created by the VPC wizard, are not auto-assigned public IPv4 addresses. Instances launched in the public subnet must be assigned a public IPv4 address to communicate with the Amazon ECS service endpoint.

To modify your public subnet's IPv4 addressing behavior

In the left navigation pane, choose Subnets.
Select the public subnet for your VPC. By default, the name created by the VPC wizard is Public subnet.
Choose Actions, Modify auto-assign IP settings.
Select the Enable auto-assign public IPv4 address check box, and then choose Save.

Step 3: Create Additional Subnets

The wizard creates a VPC with a single public and a single private subnet in a single Availability Zone. For greater availability, you should create at least one more of each subnet type in a different Availability Zone so that your VPC has both public and private subnets across two Availability Zones.

To create an additional private subnet

In the left navigation pane, choose Subnets.
Choose Create Subnet.
For Name tag, enter a name for your subnet, such as Private subnet.
For VPC, choose the VPC that you created earlier.
For Availability Zone, choose a different Availability Zone than your original subnets in the VPC.
For IPv4 CIDR block, enter a valid CIDR block. For example, the wizard creates CIDR blocks in 10.0.0.0/24 and 10.0.1.0/24 by default. You could use 10.0.3.0/24 for your second private subnet.
Choose Yes, Create.

To create an additional public subnet

In the left navigation pane, choose Subnets and then Create Subnet.
For Name tag, enter a name for your subnet, such as Public subnet.
For VPC, choose the VPC that you created earlier.
For Availability Zone, choose the same Availability Zone as the additional private subnet that you created in the previous procedure.
For IPv4 CIDR block, enter a valid CIDR block. For example, the wizard creates CIDR blocks in 10.0.0.0/24 and 10.0.1.0/24 by default. You could use 10.0.2.0/24 for your second public subnet.
Choose Yes, Create.
Select the public subnet that you just created and choose Route Table, Edit.
By default, the main route table is selected. Choose the other available route table so that the 0.0.0.0/0 destination is routed to the internet gateway (igw-xxxxxxxx) and choose Save.
With your second public subnet still selected, choose Subnet Actions, Modify auto-assign IP settings.
Select Enable auto-assign public IPv4 address and choose Save, Close.

2. Building and Packaging Containerized Applications

Choosing a Containerization Technology

Containerization has become a popular approach for packaging and deploying applications. Several containerization technologies are available, including Docker, containerd, and others. In this tutorial, you will focus on Docker as the containerization technology of choice.

Introduction to Docker

Docker has revolutionized the way developers package and deploy applications, offering a lightweight and portable solution for containerization. With Docker, developers can create self-contained units called containers that encapsulate their applications and all their dependencies, including libraries, frameworks, and runtime environments. This approach ensures that applications run consistently across different environments, from development to production, regardless of the underlying infrastructure.

One of the key benefits of Docker is improved application isolation. By leveraging containerization, applications are encapsulated within their own runtime environment, isolated from the host system and other applications. This isolation prevents conflicts between dependencies and ensures that applications operate reliably and predictably.

Furthermore, Docker brings consistency to application deployment. With Docker containers, developers can create a standardized environment, ensuring that applications behave consistently across different development machines, testing environments, and production servers. This eliminates the "works on my machine" problem and facilitates smoother collaboration between teams.

Simplified deployment is another advantage provided by Docker. With Docker containers, developers can package their applications and dependencies into a single, self-contained unit that can be easily distributed and deployed on any system supporting Docker. This portability enables seamless deployment across different cloud platforms, on-premises servers, or even developer laptops, reducing deployment complexities and enabling efficient scaling of applications.

Additionally, Docker promotes scalability and resource efficiency. Its lightweight nature allows for quick provisioning and deployment of containers, enabling rapid scaling of applications based on demand. Containers consume fewer resources compared to traditional virtual machines, making more efficient use of system resources and allowing for higher density of application instances on a single host.

Setting Up Docker on AWS

Docker is a popular containerization technology that enables developers to package and deploy applications in lightweight and portable containers. Amazon Web Services (AWS) provides a robust infrastructure for running Docker containers. This guide will walk you through the steps to set up Docker on AWS.

Step 1: Create an AWS Account

If you don't have an AWS account already, go to the AWS website (https://aws.amazon.com/) and click on "Create an AWS Account." Follow the instructions to set up your account. You will need to provide billing information and create a new IAM user with appropriate permissions.

Step 2: Launch an EC2 Instance

Once you have an AWS account, launch an EC2 instance to host your Docker containers. Follow these steps:

Open the AWS Management Console and navigate to the EC2 service.
Click on "Launch Instance" to start the instance creation process.
Choose an Amazon Machine Image (AMI) that supports Docker, such as Amazon Linux 2 or Amazon ECS-optimized AMI.
Select an instance type based on your application's requirements.
Configure the instance details, such as the number of instances, VPC settings, and security groups.
Add storage and configure any additional settings as needed.
Review your configuration and launch the instance.

Step 3: Connect to the EC2 Instance

After the EC2 instance is launched, you need to connect to it using SSH. Follow these steps:

Locate the public IP address or DNS name of your EC2 instance in the AWS Management Console.
Open a terminal on your local machine and run the following command, replacing your-instance-ip with the IP address or DNS name:

ssh -i your-key-pair.pem ec2-user@your-instance-ip

Note: You may need to adjust the SSH command based on the operating system and key pair you used during the EC2 instance setup.

Step 4: Install Docker on the EC2 Instance

Once connected to the EC2 instance, install Docker by executing the following commands:

Update the package index: sudo yum update -y
Install Docker: sudo amazon-linux-extras install docker -y
Start the Docker service: sudo service docker start
Add the ec2-user to the Docker group to run Docker commands without using sudo: sudo usermod -a -G docker ec2-user

Step 5: Verify the Docker Installation

To confirm that Docker is installed and running correctly on the EC2 instance, run the following command:

docker info

If Docker is installed properly, you will see information about the Docker version and configuration.

Deploying and Managing Docker Containers on AWS EC2

Once you have Docker set up on your AWS EC2 instance, you can begin deploying and managing Docker containers. This guide will walk you through the steps to deploy and manage Docker containers on your AWS EC2 instance.

Step 1: Prepare your Docker Image

Before deploying a container, ensure you have a Docker image ready for your application. You can either build your own Docker image using a Dockerfile or pull an existing image from a registry like Docker Hub.

Step 2: Pull or Load the Docker Image

If you are using an existing Docker image from a registry, use the docker pull command to fetch the image onto your EC2 instance. For example:

docker pull your-image:tag

If you have a locally-built Docker image or a saved image file, use the docker load command to load the image into Docker on your EC2 instance. For example:

docker load -i your-image.tar

Step 3: Run the Docker Container

To deploy a Docker container based on your image, use the docker run command. Customize the command based on your application's requirements. Here's an example:

docker run -d --name your-container -p host-port:container-port your-image:tag

Replace your-container with a desired name for your container, host-port with the port number on your EC2 instance you want to map to the container's port, and container-port with the port your application listens on inside the container.

Step 4: Manage and Monitor Docker Containers

You can manage and monitor your Docker containers on your EC2 instance using various Docker commands. Here are some commonly used commands:

docker ps: Lists the running containers on the EC2 instance.
docker stop container-id: Stops a running container. Replace container-id with the actual container ID or name.
docker start container-id: Starts a stopped container.
docker logs container-id: Displays the logs of a specific container.
docker exec -it container-id /bin/bash: Accesses the terminal inside a running container for executing commands or debugging.

Step 5: Clean Up Unused Containers

To keep your EC2 instance clean and efficient, it's essential to remove unused containers. Use the docker rm command followed by the container ID or name to remove a stopped container. For example:

docker rm container-id
Be cautious while removing containers as it permanently deletes the container and its associated data.

Step 6: Automate Container Deployment and Management

To streamline container deployment and management, consider using container orchestration tools like Amazon Elastic Container Service (ECS) or Kubernetes on AWS. These tools provide more advanced features, such as automatic scaling, load balancing, and improved container management capabilities.

Feel free to visit the official Amazon Container Documentation Website and explore further resources from Amazon

Getting Started with AWS Containers Part One

Gino Osahon — Wed, 12 Jul 2023 09:18:28 +0000

Welcome to Getting Started with AWS Containers.

Overview

In this 2 part series blog post, you will go through a step-by-guide to understanding the concepts of Containers, AWS container services, Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service (EKS), Docker, How to setup ECS, Building and Packaging Containerized Applications, AWS IAM, VPC, and Deploying ECS containers. Not to worry, if these terms are new to you — you'll get introduced to them in this article!

The following topics will be covered in this first part of the tutorial.

Introduction to Containers
- Brief explanation of containers and their benefits
- Introduction to AWS container services
Understanding Containers on AWS
- Introduction to Amazon Elastic Container Service (ECS)
- Key features of ECS
- Differences between Fargate and EC2 launch types
Introduction to Amazon Elastic Kubernetes Service (EKS)
- Key features of EKS
- Comparison of ECS and EKS for container orchestration

Prerequisites

To follow this tutorial, you should have knowledge in:

Cloud Technologies/computing
Software Development and Deployment

1. Introduction to Containers

A Container is a portable and lightweight computing environment. It houses all the system resources that an application, for example, Microservices needs to run. Some examples of these resources include memory, storage, networking resources, dependencies, binary code, configurations files, and CPU. Containers allow you to package your application together with system resources, providing isolated environments for running your Applications.

Modern software engineering practices encourages containerising application deployment for a consistent delivery and management of applications for users. find below some of the benefits of containerisation in application deployment.

Portability - Write once, run anywhere. Containers can help developers bundle all their application dependencies, so no need to rebuilding the application when deploying to any other environment.
Efficiency - Containers provide one of the most efficient methods of virtualisation for developers. They minimise overhead and utilises all available resources. Isolated containers can perform their operations without interfering with other containers, allowing a single host to perform many functions.
Agility - Containerisation makes DevOps workflow seamless and easy. They can rapidly be deployed on any environment, and used to handle application functionalities. If they are not longer needed, you can automatically shut it down until it is needed again, a technique known as orchestration. Technologies like Kubernetes automate the process of coordinating, managing, scaling, and removing containers.
Faster delivery - Developers can use containers to compartmentalize their application. They can divide big application into discrete parts using microservices, and make isolated changes to areas of the application without affecting the whole application.
Improved Security - Being able to isolate components of an application provides an additional layer of security. This is because containers are isolated from one another, this way, if security on one container is compromised, other containers on the same host remain secure.
Flexibility - Containerized apps using microservices become so flexible that you can host certain elements on bare metal and deploy others to virtual cloud environments
Easier management - Platforms like Kubernetes, Google Kubernetes Engine (GKE), and Amazon Elastic Container Service (ECS/EKS) offers a variety of tools that simplify container management, like application installation, rollbacks and upgrades. There are self-healing features you can use to attempt to recover failed containers, terminate containers that fail health checks, and constantly monitor your containers’ health and status. There is also the flexibility of allocating each container a set amount of CPU and RAM to handle its tasks. Managing containers with tools like Kubernetes is way easier than traditional application management methods.

Containers help the DevOps process by accelerating deployment, streamlining workflows, and minimizing infrastructure conflicts; it also enables developers to use the available resources better. Modern tools like Kubernetes and the Docker engine has made the process of containerising application something that developers can leverage to build scalable applications

Introduction to AWS Containers

Considering that Cloud Computing is the productive way of deploying and delivering application services to users, the introduction of the AWS container services is at the forefront of this campaign. It opens the gateway to a world of boundless possibilities. Developers and IT enthusiasts immerse themselves in containerisation due to the abovementioned benefits. With its effortless management of containerized applications, Amazon Elastic Container Service (ECS) beckons users to a seamless experience, regardless of scale, where intricate complexities fade into the background, allowing creative minds to focus solely on innovation.

Amazon container services enable developers to orchestrate containers with the unparalleled powers of Kubernetes, granting DevOps Engineers the ability to control containerized deployments with finesse and precision. It enables DevOps Engineers to explore the capabilities of the Cloud concept of application development, unleashing container-based architecture's full potential.

Amazon Cloud Services has a diverse and supportive community of contributors and a well-documented resource; this creates a sense of belonging and provides a passionate community about the containerized community. Though the challenges of configuring IAM roles, building container images, and navigating the intricacies of ECS or EKS may present occasional obstacles, As the curtain rises on the Introduction to AWS container services, individuals step into a realm where dreams of scalability, flexibility, and seamless deployments are within reach, evoking a sense of wonder at the infinite possibilities awaiting them in the cloud's embrace.

2. Understanding Containers on AWS

Introduction to Amazon Elastic Container Service (ECS)

Amazon Elastic Container Service (ECS) is a fully managed container orchestration service that enables developers to quickly deploy, manage, and scale containerized applications. It also has AWS configuration and operational best practices built in. ECS is integrated with AWS and third-party tools, such as Amazon Elastic Container Registry and Docker. This integration makes it easier for teams to focus on building the applications, not the environment.

There are three layers in Amazon ECS:

Capacity - The infrastructure where your container run
Controller - Deploy and manage your applications that run on the containers
Provisioning - The tools that you can use to interface with the scheduler to deploy and manage your applications and containers.

The following diagram shows the Amazon ECS layers.

Amazon ECS capacity Layer

This is the infrastructure layer where your containers run, and it is made up of the following components.

Amazon EC2 instances in the AWS cloud - This is where you choose the instance type, number of instances, and where you can also manage the capacity.
Serverless (AWS Fargate) in the AWS cloud - Fargate is a serverless pay-as-you-go compute engine. With Fargate you don't need to manage servers, handle capacity planning, or isolate container workloads for security.
On-premises virtual machines (VM) or servers - This component allows you to register an external instance such as an on-premises server or virtual machine, to your Amazon ECS cluster.

Amazon ECS controller layer

The Amazon ECS scheduler is the software that manages your applications.

Amazon ECS provisioning layer

There are multiple options for provisioning Amazon ECS:

AWS Management Console — Provides a web interface that you can use to access your Amazon ECS resources.
AWS Command Line Interface (AWS CLI) — Provides commands for a broad set of AWS services, including Amazon ECS.
AWS SDKs — Provides language-specific APIs and takes care of many of the connection details. These include calculating signatures, handling request retries, and error handling.
Copilot — Provides an open-source tool for developers to build, release, and operate production ready containerized applications on Amazon ECS.
AWS CDK — Provides an open-source software development framework that you can use to model and provision your cloud application resources using familiar programming languages.

key features of Amazon ECS:

Options to run your applications on Amazon EC2 instances, a serverless environment, or on-premises VMs.
Integration with AWS Identity and Access Management (IAM). You can assign granular permissions for each of your containers.
AWS managed container orchestration with operational best practices built-in, and no control plane, nodes, or add-ons for you to manage.
Continuous integration and continuous deployment (CI/CD). This is a common process for microservice architectures that are based on Docker containers.
Support for service discovery. This is a key component of most distributed systems and service-oriented architectures. With service discovery, your microservice components are automatically discovered as they're created and terminated on a given infrastructure.
Monitoring and logging

Differences between Fargate and EC2 launch types

Amazon Fargate and EC2 launch types are two options available within Amazon Elastic Container Service (ECS) for running containers. Here are four key differences between them:

Serverless vs. Self-managed Infrastructure:
- Fargate: Fargate is a serverless compute engine for containers. With Fargate, you don't need to provision or manage any underlying infrastructure. AWS takes care of server provisioning, scaling, and management, allowing you to focus solely on deploying and running your containers.
- EC2: EC2 launch type, on the other hand, requires you to manage and provision EC2 instances to run your containers. You need to choose the instance types, manage capacity, and handle auto-scaling to ensure the availability and performance of your containers.
Granularity of Control:
- Fargate: Fargate offers a high level of abstraction, making it easy to deploy and manage containers without worrying about the underlying infrastructure details. However, this also means that you have less granular control over the underlying resources, such as the host operating system or the networking stack.
- EC2: With EC2 launch type, you have more control over the EC2 instances that run your containers. This enables you to fine-tune the instance configuration, use custom AMIs, and apply advanced networking configurations as needed.
Billing Model:
- Fargate: Fargate follows a pay-as-you-go pricing model, where you are charged based on the vCPU and memory resources your containers consume, and you don't pay for idle resources. This model can be cost-effective for workloads with variable or unpredictable traffic patterns.
- EC2: EC2 launch type is billed based on the EC2 instances you provision, regardless of whether your containers fully utilize the available resources or not. As a result, the cost may be higher for workloads that experience fluctuations in demand or have inconsistent resource utilization.
Ease of Management:
- Fargate: Fargate is designed for simplicity and ease of management. AWS handles all the infrastructure tasks, such as patching, updates, and scaling, allowing you to focus solely on managing your containerized applications.
- EC2: While EC2 launch type provides more control over the underlying instances, it also requires more management effort on your part. You need to monitor the instances, apply updates, manage security, and handle scaling based on demand.

When choosing between Amazon Fargate and EC2 launch types, consider factors such as the level of control required, workload characteristics, and cost considerations. Fargate is well-suited for developers who want to abstract away infrastructure management and focus on application development, while EC2 launch type provides more flexibility and control for users who require custom configurations and fine-tuning of the container environment.

3. Introduction to Amazon Elastic Kubernetes Service (EKS)

The Introduction to Amazon Elastic Kubernetes Service (EKS) unveils a realm of boundless possibilities for container orchestration. Amazon EKS is a managed Kubernetes service to run Kubernetes in the AWS cloud and on-premises data centers.

In the cloud, Amazon EKS automatically manages the availability and scalability of the Kubernetes control plane nodes responsible for scheduling containers, managing application availability, storing cluster data, and other key tasks. With Amazon EKS, you can take advantage of all the performance, scale, reliability, and availability of AWS infrastructure and integrations with AWS networking and security services.

As the managed Kubernetes service provided by AWS, EKS empowers developers to effortlessly deploy, manage effortlessly, and scale containerized applications using the powerful Kubernetes platform. With EKS, the complexities of setting up and maintaining a Kubernetes cluster fade into obscurity as AWS shoulders the burden of infrastructure management and ensures high availability and resilience.

The journey into Amazon EKS embarks on a voyage of innovation, collaboration, and enhanced agility, inviting newcomers and seasoned Kubernetes enthusiasts to navigate the waters of container orchestration with confidence and unbridled excitement.

Key features of the Amazon Elastic Kubernetes Service

The Amazon Elastic Kubernetes Service (EKS) offers an array of features that spark feelings of excitement and confidence in the hearts of developers and IT teams alike:

Seamless Scalability: The scalability of EKS invokes a sense of liberation, as it effortlessly adapts to varying workloads. Whether it's a surge in traffic during peak hours or a sudden influx of users, EKS dynamically adjusts resources, alleviating the fear of application slowdowns and ensuring a smooth user experience.
Streamlined Deployment: EKS' streamlined deployment process ignites enthusiasm, as it allows developers to swiftly roll out containerized applications without getting entangled in the intricacies of Kubernetes cluster setup. The ease of use empowers teams to focus on innovation, inspiring them to bring their ideas to life with unparalleled efficiency.
High Availability and Reliability: The reliability of EKS evokes a sense of trust and security, knowing that the applications will remain accessible and stable, even during challenging times. With built-in redundancy and automated failover mechanisms, EKS provides a safety net that bolsters confidence in the face of uncertainty.
Intelligent Auto-scaling: EKS' intelligent auto-scaling capabilities elicit feelings of awe, as it intuitively monitors application demand and adjusts resources accordingly. The knowledge that the infrastructure can autonomously handle traffic spikes and downturns instills a sense of peace, allowing teams to focus on innovation without fearing performance bottlenecks.
Seamless Integrations: The seamless integration of EKS with other AWS services brings a sense of unity and harmony to the cloud ecosystem. It inspires collaboration between applications and services, amplifying the potential for building feature-rich, interconnected solutions that delight users and customers alike.
Enhanced Security: The robust security measures of EKS generate feelings of assurance and peace of mind. From role-based access control to automated security updates, EKS creates a shield of protection around the containerized applications, ensuring data integrity and safeguarding against cyber threats.
Community and Support: The strong EKS community and AWS support invoke feelings of camaraderie and belonging. Knowing that there is a vast network of experts, resources, and documentation to lean on fosters a sense of empowerment, enabling developers to explore the full potential of Kubernetes with a safety net of knowledge.

Comparison of ECS and EKS for container orchestration

When comparing Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS) for container orchestration, it elicits a range of emotions that stem from the unique strengths and characteristics of each service:

Simplicity and Ease of Use (ECS): ECS evokes feelings of simplicity and ease of use, offering a straightforward approach to container orchestration. It allows developers to focus on their applications without the added complexity of managing Kubernetes infrastructure. The simplicity of ECS fosters a sense of relief, enabling quick deployments and reducing the learning curve for teams, particularly those new to containerization and orchestration.
Flexibility and Community (EKS): EKS sparks feelings of excitement and curiosity due to its inherent flexibility and the vibrant Kubernetes community it embraces. EKS opens doors to a vast ecosystem of tools, plugins, and knowledge, nurturing a sense of empowerment and inspiration. This flexibility fosters a spirit of exploration, enabling teams to leverage the rich Kubernetes feature set, custom configurations, and integration possibilities to build innovative and scalable solutions.
Managed Infrastructure (ECS): ECS invokes a sense of relief and peace of mind with its managed infrastructure. Teams appreciate the freedom from infrastructure management responsibilities, allowing them to focus on application development and deployment. This managed approach evokes feelings of security and trust, knowing that AWS handles the underlying infrastructure, patching, and scaling, thus relieving the burden of operational tasks and enabling teams to concentrate on delivering high-quality applications.
Granularity and Control (EKS): EKS elicits feelings of control and precision, appealing to developers seeking fine-grained control over their container orchestration environment. The ability to customize Kubernetes configurations, choose specific container runtimes, and access advanced networking options invokes a sense of empowerment and confidence. EKS provides a playground for meticulous fine-tuning, creating an atmosphere of excitement and satisfaction among those who desire a high level of control.

Let's end the first part of the 2 part series article here and continue in article two. You will learn about the following topics in article 2.

Setting Up AWS for Containers
- Creating an AWS account
- Configuring AWS Identity and Access Management (IAM) roles and policies
- Creating a VPC with Public and Private Subnets for Your Clusters
Building and Packaging Containerized Applications
- Choosing a containerization technology (Docker, containerd, etc.)
- Introduction to Docker
- Setting Up Docker on AWS
- How to deploy and manage Docker containers on AWS EC2

Feel free to visit the official Amazon Container Documentation Website and explore further resources from Amazon

Click here to go to article 2

How to Convert BTC to RBTC Using The 2-Way Peg App

Gino Osahon — Wed, 26 Oct 2022 09:13:42 +0000

Overview

The 2 way peg is a protocol to convert BTC to RBTC and vice versa. It is secured by the powpeg, which is a unique 2-way peg system that secures the locked bitcoins with the same Bitcoin hashrate that establishes consensus. See the history of the Powpeg.

The 2 way peg is a web application that fosters the interaction between the bitcoin blockchain and the RSK network for easier exchange of BTC and RBTC. It provides a way to visualize the status of transactions, communicate with a user wallet (both hardware wallets and software wallets), while also providing the highest possible level of security for transactions.

In this guide, we are going to learn how to use the 2 way peg app application, its features, benefits, how to use hardware and software wallets to perform peg-ins, and how to view transaction statuses. This guide also provides more advanced operation instructions including how to use different wallets, selecting fees, et cetera.

Note: Current version (v1.1.0) of the 2 way peg app does not support peg-outs.

How it Works

The 2 way peg app uses a REST API and a 2 way peg api as the backend, this API uses a daemon process, which is responsible for listening on blockchain transactions to update the state of peg-ins and in the future, the state of peg-outs, these state changes (tx hash, date change, last status) are stored in a mongodb database.

Currently, the 2 way peg app is available on both RSK Mainnet and RSK Testnet.

The source code is available on github, and open source:

Features

The 2 way peg app, has two primary features, they are:

Peg-in: A conversion from BTC to RBTC. See Glossary section for more explanation.
- Note: The peg-in process is final and cannot be reverted.
Peg-out: A conversion from RBTC to BTC. This current version of the 2 way peg app (v1.1.0) does not support the peg-out functionality.

Why use the 2 way peg?

The 2 way peg application has lots of benefits, these include:

Simplified transactions

The peg-in in its nature is a complex process and this app makes it simpler. Using the 2 way peg app enables you to choose where to receive the converted BTC, which is also possible without it, but with an even higher level of complexity than a legacy peg-in.

Visualization of transactions

Enables the visualization of the status of transactions on the RSK network

Enables communication with a user wallet (hardware and software)

The 2 way peg app communicates directly with the following services:

Trezor: Directly via usb
Ledger: Directly via usb and integrated with the manufacturer's application
Liquality: Directly through the application provided by the company
Nifty: Through the rLogin application
Metamask: Through the rLogin application. Learn more about the rLogin application

Secure transactions

All transactions need to be confirmed via the device used by the customer, whether a hardware or software wallet, all transaction information and the appropriate signatures are generated through integration with the wallets.

Be sure to check out our next article How to get started using the 2 way peg app on the RSK Developer Portal.

This article was originally posted on the RSK Developer Portal.

Resources

2 way peg app frontend repo
2 way peg app backend repo
How to get RBTC using RSK’s built in Powpeg
RSK Testnet Faucet
Get RBTC using Exchanges

Overview - The Complete Guide to Decentralized Exchanges (DEX)

Gino Osahon — Tue, 20 Sep 2022 08:28:48 +0000

In this guide, you will learn about decentralized exchanges (DEX), types of DEXes, features of a DEX - lending, borrowing and yield farming. We will explore the differences between a centralized exchange(CEX) and a DEX, On-chain order books, Off-chain order books, Automated Market Makers (AMM), and the different types of DEXes oN RSK.

Overview

What is a DEX?

A decentralized exchange, also known as DEX, is a peer-to-peer trading platform where cryptocurrency holders and traders make transactions directly without handing over management of their funds to an intermediary or a custodian. DEXes have become a pivotal element in the crypto world by enabling trading with considerable improvements in crypto volume.

How DEXes Work

A decentralized exchange (DEX) excludes the need for any centralized authority, supervision, and authorization of transactions on exchanges. DEXes allow for peer-to-peer cryptocurrency trading by linking crypto buyers and sellers together. DEXes are both custodial and non-custodial in nature. A non-custodial exchange platform means users have control and ownership of their private keys.

Types of DEXes

Order Book DEXes

Order books maintain records of all the open orders for purchasing and selling assets for specific pairs of assets. The buy orders imply a trader’s interest in purchasing or bidding for an asset at a particular price. While, sell orders show that the trader is prepared to selling by asking for a specific price for the concerned asset.

On-chain order books

These DEXes store their open order information on the blockchain, and are referred to as on-chain order book DEXes. On-chain order book DEXes could help traders in leveraging their positions by using funds from lenders on their platform.

Off-chain order books

Off-chain order book DEX platforms store the order books outside of the blockchain networks. The off-chain order book DEXes only perform transaction settlement on the blockchain, thereby offering the value of centralized crypto exchanges.

The notable examples of order book DEXes on RSK include:

DEX Aggregators

These are trading protocols that work by sourcing and routing liquidity throughout multiple DEXes according to specified requirements. DEX aggregators don’t have any need for servicing traders exclusively from their own liquidity pools. This enables DEX aggregators to play a crucial role in delivering efficient approaches for crypto trading.

Automated Market Makers

The automated Market Maker (AMM) system uses smart contracts efficiently to address the liquidity problem. Rather than matching the buy orders and sell orders, the smart contracts in AMM-based decentralized exchanges could leverage liquidity pools. The liquidity pools are basically pre-funded pools of assets, which serve an important role in the working of AMM-based DEXes.

AMMs leverage blockchain-based services for obtaining information from exchanges and other platforms for setting the price of traded assets. These price feed services are provided by blockchain oracles like Chainlink, API3, Chainbeat,
and Oracle MOC

Users provide funding for the liquidity pools and get rewarded with transaction fees allocated for trades on the concerned pair. Such types of users, also known as liquidity providers execute orders. Traders could also earn interest in a trustless and permissionless manner. AMM-based DEXes are generally ranked on the basis of the total amount of funds locked in their smart contracts.

The AMM-based DEXes can encounter slippage, which emerges due to a lack of liquidity. Slippage is evident when the lack of liquidity leads to the buyer paying more than the market price on their orders. In such cases, the larger orders are more likely to encounter higher slippage. Furthermore, liquidity providers could also face the risks of impermanent loss due to the volatility of one asset in trading pairs.

The notable examples of AMM DEXes on RSK include Sovryn, Blindex, and RSKSwap.

Be sure to check out our next article in this guide, about The difference between a Centralized and a Decentralized Exchange on the RSK Developer Portal.

This article was originally posted on the RSK Developer Portal.

The difference between stablecoins and other digital assets

Gino Osahon — Wed, 14 Sep 2022 09:22:30 +0000

In this section, we will cover the difference between a stablecoin and other digital assets like bitcoins, fiat currency, fungible tokens, Central Bank Digital Currency (CBDCs), and Altcoins.

Stablecoin vs Bitcoins

A stablecoin is a token that has a non-volatile price and Bitcoin is a cryptocurrency whose price is volatile in nature. Stablecoins are used to minimize the price volatility of cryptocurrencies like Bitcoins.

Stablecoin vs Altcoin

Altcoins are cryptocurrencies other than Bitcoin. Similar comparisons apply, with regards to volatility.

Stablecoin vs Fiat

Stablecoins are issued by crypto companies that are backed by traditional financial investment tools. They can be pegged to any fiat currency, foreign exchange-traded commodities, precious or industrial metals.

While fiat currencies are issued by central banks, they are not asset-backed. Their value depends on the central bank. The central bank can regulate the total supply in circulation by printing and withdrawing them from use.

Stablecoin vs Fungible Tokens

A stablecoin is a type of fungible token whose value is fixed to another asset, often currencies such as the US dollar or the Euro, and other assets.

Read: Cryptocurrency vs Token or watch the explainer video below:

YouTube:

Stablecoin vs CBDCs

A stablecoin may or may not be regulated, while Central Bank Digital Currency (CBDC) is completely regulated by the monetary authorities of a nation. This means stablecoins are decentralized while CBDCs are centralized. Furthermore, CBDCs may be implemented with fungible tokens, in a manner similar to stablecoins, or they may be implemented using other technologies, including centralised ones.

See the Complete Guide to Stablecoins on the RSK Developers Portal.

Thanks for reading!

Introduction | Deploy an NFT project on the RSK Testnet

Gino Osahon — Wed, 27 Jul 2022 14:33:00 +0000

Welcome to the Complete Guide on How to Create and Deploy an NFT Smart Contract on RSK.

Introduction

In this tutorial, we will take you through a step by step process on how to write a ERC-721 smart contract, and deploy to the RSK testnet using the following tools: Solidity, Hardhat, Ether.js, RSK Testnet, IPFS, Pinata, and Test RBTC from a faucet. Not to worry, if these terms are new to you - we will explain them!

We will do the following in this tutorial.

A brief introduction to NFTs, and ERC-721
Setting up your environment
What is IPFS?
How to set up your Pinata account
Create NFT metadata (JSON File)
Create ERC 721 smart contract
Deploy smart contract on the RSK blockchain

Prerequisites

To follow this tutorial, you should have knowledge in:

Smart contract fundamentals using Solidity
JavaScript
Command line
Git

If you are not familiar with the above, it will be advisable to learn the basics by clicking the links above, before proceeding with this tutorial on how to create and deploy your NFT project to the RSK Testnet.

What is a Non-fungible Token (NFT)?

Fungibility, is about whether something is interchangeable and divisible. A fungible token has both of those properties, and behave in a manner similar to fiat cash; whereas a non-fungible token is neither interchangeable nor divisible, and behave in a manner similar to many real-world objects.

ERC-20 is the most commonly used technical standard for fungible tokens (FTs); and ERC-721 is the most commonly used technical standard for non-fungible tokens (NFTs).

Non-fungible is a term used to describe digital assets that represent real-world objects like art, furniture, a song file, in-game items, your computer, or even real estate. Unlike ERC-20 tokens, tokens that are created under ERC-721 are not interchangeable, this comes from the fact that while two NFTs may look identical to each other, they both hold unique information. Non-fungible tokens also lack another feature of their ERC-20 counterparts - they are not divisible, which means that you cannot own a portion of an NFT.

NFTs can be used in the following use cases:

Medical Records and Identity Verification - NFT ledgers can store an individual's medical records without compromising confidentiality or risking tampering from external sources
Real Estate - NFTs could be used to transfer land deeds, provide proof of ownership and even keep track of changes in property value over time using timestamped NFTs.
Ensuring Authenticity of Products - NFTs can be used to ensure that the product you are purchasing is authentic. NFTs can also be used to store information about the manufacturing process, ensuring that everything is fair trade
Academic Credentials - NFTs are also a good way to represent academic credentials. NFTs can provide proof of attendance, degree earned, and other important information which will be stored on the NFT chain that cannot be altered or hacked into.
Gaming Industry - NFTs can be integrated into the gaming world by allowing NFT cross-platform playability.

What is ERC-721?

ERC-721 is a standard for representing ownership of non-fungible tokens, where each token is unique. It provides functionalities like to transfer tokens from one account to another, getting the current token balance of an account, getting the owner of a specific token, and also the total supply of the token available on the network.

EIP-721 is a standard interface for non-fungible tokens.

**Setting up your Development Environment

What is Hardhat?**

Hardhat is a development environment that enables you to compile, deploy, test, and debug your RSK software. It helps to manage and automate the recurring tasks that are inherent to the process of building Blockchain applications.

Check out this step-by-step tutorial on how to set up a Hardhat project to connect to the RSK Testnet.

What is ethers.js?

Ethers.js is a JavaScript library that allows developers to interact with the blockchain. The library includes utility functions in JavaScript and TypeScript, and can also support wallets.

What is tRBTC (Smart Bitcoin in Testnet)?

The Test Smart Bitcoin (tRBTC) is the token used to pay for the execution of transactions in the RSK Testnet environment.
Watch this video tutorial on How to Get tRBTC from the RSK Testnet Faucet.

What is IPFS?

IPFS (Interplanetary File System) is a file system/protocol for storing and sharing content, it allows you to store files, keeping track of them on a distributed network. This storage system allows direct interaction through a secure and global P2P network.

IPFS files are content-addressable. This means that it uses content identifiers, or CIDs, as a label to point to material in IPFS. These CIDs are based on the contents of the files themselves, and may be thought of as hashes. It doesn't indicate where the content is stored, but it forms a kind of address based on the content itself. This property makes IPFS a suitable platform for referencing images within smart contracts. We will use IPFS to host/store our NFT images.

Configure the metadata for your NFT using Pinata

To get our tokenURI parameter, which should resolve to a JSON document describing our NFT's metadata which will include properties such as name, description, image, and other attributes, we would need to set up Pinata, a convenient IPFS API and toolkit, to store our NFT asset and metadata.

To simply put, a tokenURI on an NFT is a unique identifier of what the token "looks" like. A URI could be an API call over HTTPS, an IPFS hash, or anything else that is unique.

If you don't have a Pinata account, sign up for a free account here and complete the steps to verify your email.

Once you've created an account:

Navigate to the "Files" page and click the blue "Upload" button at the top-left of the page.
Upload two cat images to Pinata - this will be the image asset for your NFTs. Feel free to name the asset whatever you wish
After you upload, you'll see the file info in the table on the "Files" page. You'll also see a CID column. You can copy the CID by clicking the copy button next to it. You can view your upload at: https://gateway.pinata.cloud/ipfs/.

Now, let's create and upload two other files to pinata, each containing details of two cats in JSON format.

In your root directory, make a new folder called nft- metadata and add the following json codes:

File one is named doerak.json

{
 "attributes": [
 {
 "trait_type": "Breed",
 "value": "European short hair"
 },
 {
 "trait_type": "Parent",
 "value": "Gino Osahon"
 }
 ],
 "description": "Doerak. Gray & white kitty",
 "image": "ipfs://QmX7P1aswXLKLPd7RqbtwrNGD9CzGjvNFKmdEhWtBmoyiS",
 "name": "Doerak"
}

File two is named luna.json

{
 "attributes": [
 {
 "trait_type": "Breed",
 "value": "European short hair"
 },
 {
 "trait_type": "Parent",
 "value": "Alex Shenshin"
 }
 ],
 "description": "Luna. Ginger kitty",
 "image": "ipfs://QmZZfJcrppaRiq5dWtC6zpnGZRNoVwdyh69VoA89xGW5Yt",
 "name": "Luna"
}

Feel free to change the data in the json. You can remove or add to the attributes section. Most importantly, make sure the image field points to the location of your IPFS image.
Once you're done editing the JSON file, save it and upload it to Pinata, following the same steps we did for uploading the image.

Generate a seed phrase

In your root directory, create a file called secret.json and add your seed phrase.

Seed phrases are a human-readable version of your private keys. You can sign transactions and recover lost accounts using part of your mnemonic phrase. Mnemonic or seed phrases can range from 12–24 words depending on the blockchain ecosystem you are dealing with. Any app can generate its mnemonic phrase for security purposes.

{
 "mnemonic": "please put your twelve words long mnemonic phrase to this string now"
}

To interact with the RSK blockchain, you need an account, which consists of a private key, a public key, and an address.

BIP-39 is a technical standard that allows the generation of multiple accounts from a set of dictionary words, plus a derivation path. Many software libraries and wallet software implement this technical standard, including both ethers.js and MetaMask, which we'll be using in this tutorial. Note that seed phrases should be treated as securely as private keys, so do not use the one in this tutorial on RSK Mainnet- the usage here is sufficient for use on RSK Testnet only.

Hardhat Configuration

Let's explain the hardhat.config.js file, the configuration file is always executed on startup before anything else happens, and it has two main tasks. You can define a task as a JavaScript async function with some associated metadata. This metadata is used by Hardhat to automate tasks, or as asynchronous JavaScript functions that get access to the Hardhat Runtime Environment, which exposes its configuration and parameters.

task('deploy', 'Deploys smart contract to a blockchain').setAction(async () => {
 const meowContractFactory = await ethers.getContractFactory('Meow');
 const meowNft = await meowContractFactory.deploy();
 await meowNft.deployed();
 console.log(
 `Meow NFT deployed to: ${meowNft.address}\nCopy this address and paste to the 'mint' task in 'hardhat.config.js'`,
 );
});

When the deploy task is called, hardhat will deploy your smart contract to the RSK Blockchain. The function takes two metadata, and the second line const meowContractFactory = await ethers.getContractFactory('Meow'); gets a contractFactory of the compiled source code.

ContractFactory in ethers.js is an abstraction used to deploy new smart contracts, so Meow here is a factory for instances of our Meow contract.

The line const meowNft = await meowContractFactory.deploy(); sends a deploy transaction, and the next line await meowNft.deployed(); waits for the transaction to be mined. The last line in the deploy task uses console.log print logging message that says NFT has been deployed to the contract variable address.

task('mint', 'Mint new NFT collectibles').setAction(async () => {
 const deployedAddress = '0xE360F4BFb74A1B2B1d102f40BE6c7D0f5C9d12C8';
 const newCIDsToMint = [
 'QmaXZxVGYcCY36seYTVuGeY9mWchC1WjMscV1FLNfZsM3f',
 'QmR5mspowKw6B68QPSuYE9SGH1A6gPKxjdVRokhAZZh4LD',
 ];
 const api = (await ethers.getContractFactory('Meow')).interface;
 const [signer] = await ethers.getSigners();
 const meowNft = new ethers.Contract(deployedAddress, api, signer);
 async function mintSequentially() {
 const cid = newCIDsToMint.shift();
 if (cid) {
 const tx = await meowNft.mintNFT(signer.address, `ipfs://${cid}`);
 const receipt = await tx.wait();
 const { tokenId } = receipt.events[0].args;
 console.log(`Minted NFT ${deployedAddress} #${tokenId}`);
 await mintSequentially();
 }
 }
 await mintSequentially();
});

Task mint when called will mint a new NFT. The line const deployedAddress = '0xE360F4BFb74A1B2B1d102f40BE6c7D0f5C9d12C8'; takes the address where the smart contract source code was deployed to in the deploy task. This means that you need to first run the deploy task, then copy the address of the deployed source code and then assign it here to the deployedAddress constant.

The below lines contain the IPFS content identifier (CIDs) obtained from Pinata.

 const newCIDsToMint = [
 'QmaXZxVGYcCY36seYTVuGeY9mWchC1WjMscV1FLNfZsM3f',
 'QmR5mspowKw6B68QPSuYE9SGH1A6gPKxjdVRokhAZZh4LD',
];

The lines below get the smart contract application programming interface, get the deployers account information, and instantiates the smart contract representation object.

const api = (await ethers.getContractFactory('Meow')).interface;
 const [signer] = await ethers.getSigners();
 const meowNft = new ethers.Contract(deployedAddress, api, signer);

The below mintSequentially function mints all items from the newCIDsToMint array one after another. The statement const cid = newCIDsToMint.shift(); removes the first CID from the newCIDsToMint array, if the array is already empty (minted all items). The if statement is called, if there are still items to be minted, it calls the smart contracts mintNFT function thereby initiating a transaction. It then waits for the transaction to be mined, gets the transaction receipt, extracts the ID of the newly minted NFT from the transfer event emitted by the smart contract, and recursively calls itself until the newCIDsToMint array is empty.

async function mintSequentially() {
 const cid = newCIDsToMint.shift();
 if (cid) {
 const tx = await meowNft.mintNFT(signer.address, `ipfs://${cid}`);
 const receipt = await tx.wait();
 const { tokenId } = receipt.events[0].args;
 console.log(`Minted NFT ${deployedAddress} #${tokenId}`);
 await mintSequentially();
 }
 }

The module.export section has already been explained in the JSON-RPC base networks section of the "How to set up a Hardhat project for RSK Testnet " tutorial referred to in this article.

Complete Config File

Your final configuration file should now look like this:

/* eslint-disable no-undef */
require('@nomiclabs/hardhat-waffle');
const { mnemonic } = require('./.secret.json');
task('deploy', 'Deploys smart contract to a blockchain').setAction(async () => {
 const meowContractFactory = await ethers.getContractFactory('Meow');
 const meowNft = await meowContractFactory.deploy();
 await meowNft.deployed();
 console.log(
 `Meow NFT deployed to: ${meowNft.address}\nCopy this address and paste to the 'mint' task in 'hardhat.config.js'`,
 );
});

task('mint', 'Mint new NFT collectibles').setAction(async () => {
 const deployedAddress = '0xE360F4BFb74A1B2B1d102f40BE6c7D0f5C9d12C8';
 const newCIDsToMint = [
 'QmaXZxVGYcCY36seYTVuGeY9mWchC1WjMscV1FLNfZsM3f',
 'QmR5mspowKw6B68QPSuYE9SGH1A6gPKxjdVRokhAZZh4LD',
 ];
 const api = (await ethers.getContractFactory('Meow')).interface;
 const [signer] = await ethers.getSigners();
 const meowNft = new ethers.Contract(deployedAddress, api, signer);
 async function mintSequentially() {
 const cid = newCIDsToMint.shift();
 if (cid) {
 const tx = await meowNft.mintNFT(signer.address, `ipfs://${cid}`);
 const receipt = await tx.wait();
 const { tokenId } = receipt.events[0].args;
 console.log(`Minted NFT ${deployedAddress} #${tokenId}`);
 await mintSequentially();
 }
 }
 await mintSequentially();
});
module.exports = {
 solidity: '0.8.12',
 defaultNetwork: 'rsktestnet',
 networks: {
 hardhat: {},
 rsktestnet: {
 chainId: 31,
 url: 'https://public-node.testnet.rsk.co/',
 accounts: {
 mnemonic,
 path: "m/44'/60'/0'/0",
 },
 },
 },
};

Create your Smart Contract

In your root directory, start by creating a new directory called contracts and create a file inside the directory called Meow.sol.

mkdir contracts
touch contracts/Meow.sol
code contracts/Meow.sol

Below is our NFT smart contract code, which is based on the OpenZeppelin library's ERC-721 implementation. Copy and paste the contents below into your Meow.sol file.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
// using OpenZeppelin libraries
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
contract Meow is ERC721URIStorage, Ownable {
 /** 
 From the `Counters` docs:
 Provides counters that can only be incremented, decremented or reset. 
 This can be used e.g. to track the number
 of elements in a mapping, issuing ERC721 ids, or counting request ids.
 Include with `using Counters for Counters.Counter;` 
 */
using Counters for Counters.Counter;
 // tracks the number of minted NFTs
 Counters.Counter private _tokenIds;
// calling ERC721 constructor
 constructor() ERC721("Meow NFT", "MEO") {}
// mints new NFTs. Can be called only by the deployer (s/c owner)
 function mintNFT(address recipient, string memory tokenURI)
 public onlyOwner
 returns (uint256)
 {
 // increment counter
 _tokenIds.increment();
 // get new NFT id
 uint256 newItemId = _tokenIds.current();
 // call internal ERC721 mint function
 _mint(recipient, newItemId);
 // write token URI to newly minted NFT
 _setTokenURI(newItemId, tokenURI);
return newItemId;
 }
}

We are inheriting classes from the OpenZeppelin contracts library, in the command line run npm install @openzeppelin/contracts to install the library into our folder.

So, what does this code do exactly? Let's break it down, line-by-line.

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";

At the top of our smart contract, we import three OpenZeppelin smart contract classes and one extension:

@openzeppelin/contracts/token/ERC721/ERC721.sol contains the implementation of the ERC-721 standard, which our NFT smart contract will inherit. To be a valid NFT, your smart contract must implement all the methods of the ERC-721 standard. To learn more about the inherited ERC-721 functions, see the full ERC-721 specification.
@openzeppelin/contracts/utils/Counters.sol provides counters that can only be incremented or decremented by one. Our smart contract uses a counter to keep track of the total number of NFTs minted and set the unique ID on our new NFT. (Each NFT minted using a smart contract must be assigned a unique ID-here our unique ID is just determined by the total number of NFTs in existence. For example, the first NFT we mint with our smart contract has an ID of 1, our second NFT has an ID of 2, etc.)
@openzeppelin/contracts/access/Ownable.sol sets up access control on our smart contract, so only the owner of the smart contract (you) can mint NFTs. Note that including access control is entirely a preference. If you'd like anyone to be able to mint an NFT using your smart contract, remove the word Ownable on line 10 and onlyOwner on line 17.
@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol - This is a more flexible but more expensive way of storing metadata.

using Counters for Counters.Counter;
 // tracks the number of minted NFTs
 Counters.Counter private _tokenIds;
// calling ERC721 constructor
 constructor() ERC721("Meow NFT", "MEO") {}

After our import statements, we have our custom NFT smart contract, which is surprisingly short - it only contains a counter, a constructor, and single function! This is thanks to our inherited OpenZeppelin contracts, which implement most of the methods we need to create an NFT, such as ownerOf which returns the owner of the NFT, and transferFrom, which transfers ownership of the NFT from one account to another.

In our ERC-721 constructor, you'll notice we passed 2 strings, Meow-NFT, and MEO. The first variable is the smart contract's name, and the second is its symbol. You can name each of these variables whatever you wish!

// mints new NFTs. Can be called only by the deployer (s/c owner)
 function mintNFT(address recipient, string memory tokenURI)
 public onlyOwner
 returns (uint256)
 {
 // increment counter
 _tokenIds.increment();
 // get new NFT id
 uint256 newItemId = _tokenIds.current();
 // call internal ERC721 mint function
 _mint(recipient, newItemId);
 // write token URI to newly minted NFT
 _setTokenURI(newItemId, tokenURI);
return newItemId;
 }

Finally, we have our function mintNFT(address recipient, string memory tokenURI) that allows us to mint an NFT! You'll notice this function takes in two variables:

address recipient specifies the address that will receive your freshly minted NFT
string memory tokenURI is a string that should resolve to a JSON document that describes the NFT's metadata. An NFT's metadata is really what brings it to life, allowing it to have configurable properties, such as a name, description, image, and other attributes.

mintNFT calls some methods from the inherited ERC-721 library, and ultimately returns a number that represents the ID of the freshly minted NFT.

How to deploy your NFT to RSK
Steps

we will do the following steps;

Switch to Node.js 12 for Hardhat to work nvm use 12
compile Meow-NFT smart contract npx hardhat compile
deploy Meow-NFT smart contract to RSK testnet. See other possible networks in hardhat.config.js npx hardhat deploy --network rsktestnet

you will see a message:

Meow NFT deployed to: 0xE360F4BFb74A1B2B1d102f40BE6c7D0f5C9d12C8 Copy this address and paste to the 'mint' task in 'hardhat.config.js'

Paste the address to the mint task!

mint your NFTs from CIDs specified in the mint task of project.config.js

npx hardhat mint --network rsktestnet

View NFT using Metamask

Metamask

Metamask is a kind of web wallet which facilitates transactions using yours accounts. It can be used with RSK networks too. It has versions for several browsers, like Chrome, Firefox, Opera and Brave.

Go to metamask.io and install it.
Create an account.

Write down your 12 word seed phrase. This is used to recover your account, in case you lose your password.

The seed phrase is the most important thing in a wallet / account!

Connect MetaMask to RSK testnet

Go to networks -> Custom RPC, and enter the following values:

Network Name RSK Testnet
New RPC URL https://public-node.testnet.rsk.co
ChainID (optional) 31
Symbol (optional) tRBTC
Block Explorer URL (optional) https://explorer.testnet.rsk.co

After configuring it, select the RSK Testnet.

MetaMask screenshot before adding NFT collection

You should now see an account connected to the RSK Testnet.
Not to worry if you see "No NFTs yet" under the NFTs tab,
there is one more step before we'll be able to see them!

Add NFT to Metamask

Once you're on the RSK network, select the "NFTs" tab on the right and add the NFT smart contract address and the ERC-721 token ID of your NFT - which you should be able to find on RSK Testnet Explorer based on the transaction hash from your NFT deployed to RSK Testnet.

You may need to refresh the page to see your newly minted NFT.
MetaMask screenshot after adding NFT collection

Congratulations! In this article, we learnt about NFTs, IPFS, Hardhat, and we have successfully created and deployed our NFT project to the RSK Testnet.

If you would like to delve deeper, here are some resources and tools that we recommend.

Resources

Visit Our Developers Portal

This article was originally posted on the RSK Developer Portal.

Forem: Gino Osahon

Getting Started with AWS Containers Part Two

Overview

Prerequisites

1. Setting Up AWS for Containers

Creating an AWS Account

Configuring AWS Identity and Access Management (IAM) Roles and Policies

Creating a VPC with Public and Private Subnets for Your Clusters

Step 1: Create an Elastic IP Address for Your NAT Gateway

Step 2: Run the VPC Wizard

Step 3: Create Additional Subnets

2. Building and Packaging Containerized Applications

Choosing a Containerization Technology

Introduction to Docker

Setting Up Docker on AWS

Step 1: Create an AWS Account

Step 2: Launch an EC2 Instance

Step 3: Connect to the EC2 Instance

Step 4: Install Docker on the EC2 Instance

Step 5: Verify the Docker Installation

Deploying and Managing Docker Containers on AWS EC2

Step 1: Prepare your Docker Image

Step 2: Pull or Load the Docker Image

Step 3: Run the Docker Container

Step 4: Manage and Monitor Docker Containers

Step 5: Clean Up Unused Containers

Step 6: Automate Container Deployment and Management

Getting Started with AWS Containers Part One

Welcome to Getting Started with AWS Containers.

Overview

1. Introduction to Containers

Introduction to AWS Containers

2. Understanding Containers on AWS

Introduction to Amazon Elastic Container Service (ECS)

There are three layers in Amazon ECS:

The following diagram shows the Amazon ECS layers.

Amazon ECS capacity Layer

key features of Amazon ECS:

Differences between Fargate and EC2 launch types

3. Introduction to Amazon Elastic Kubernetes Service (EKS)

Key features of the Amazon Elastic Kubernetes Service

Comparison of ECS and EKS for container orchestration

How to Convert BTC to RBTC Using The 2-Way Peg App

Overview

How it Works

Features

Why use the 2 way peg?

Next

Resources

Overview - The Complete Guide to Decentralized Exchanges (DEX)

Overview

What is a DEX?

How DEXes Work

Types of DEXes

Order Book DEXes

On-chain order books

Off-chain order books

DEX Aggregators

Automated Market Makers

Next

The difference between stablecoins and other digital assets

Stablecoin vs Bitcoins

Stablecoin vs Altcoin

Stablecoin vs Fiat

Stablecoin vs Fungible Tokens

Stablecoin vs CBDCs

Next

Introduction | Deploy an NFT project on the RSK Testnet