DEV Community: Khalil Chaymae

Create a container using the Ubuntu image in Docker.

Khalil Chaymae — Thu, 19 Dec 2024 23:32:52 +0000

This post explains how to create a container for an Ubuntu Linux distribution in Docker. It's very easy to do using simple commands.

Step 1:
Run Docker Desktop on your Windows machine.
step 2:
Open the Command Prompt (CMD) and type the following command.

docker pull ubuntu

Step 3 :
Run the following command to create the container.

NB: If the Ubuntu image is not present on your machine:
Docker will automatically pull the Ubuntu image from Docker Hub, which is Docker's default image registry.
Once the image is downloaded, Docker will use it to create and start the container.
If the Ubuntu image is already present on your machine:
Docker will skip the pull step and directly use the existing local copy of the Ubuntu image to create and start the container.

docker run -it --name my-ubuntu-container ubuntu

the End...

AGILE VS WATERFULL methodology

Khalil Chaymae — Fri, 17 Nov 2023 07:32:23 +0000

What is a methodology ??

A set of principles, practices, procedures, and rules that teams and organizations use to guide their work throughout the project lifecycle. The method provides a structured approach to planning, executing, and controlling information systems development or project management processes.

WaterFull methodology :

The term "waterfall" implies a one-way progression, suggesting that once a process is initiated, there is no room for alterations or revisions upon completion. For example, in the context of developing a web application to manage equipment, when the client provides specifications, any adjustments or modifications become impractical once the project is underway. In this methodology, flexibility is limited, as the work adheres to the initial specifications from start to finish.

Agile methodology:

In the Agile methodology, the project is divided into multiple iterations, with each iteration encompassing various phases. Typically lasting between 2 to 8 weeks, each iteration follows a cycle where software is developed, released, and refined based on user or customer feedback.
The Agile model operates by initially delivering a version of the software in the first iteration. Subsequently, feedback is gathered from end users or customers regarding the application's functionality and features. This feedback is then used to make improvements and incorporate necessary changes into the second iteration. The refined software is released once again into the market during the second iteration. This iterative process is repeated in subsequent cycles, allowing for continuous improvement and adaptation to evolving requirements or preferences.

In which scenarios should I choose the Waterfall model, and when is it more appropriate to opt for Agile?

The choice between the Waterfall and Agile models depends on the nature of the project. If the project has a specific goal from the outset, and the client provides a detailed specification that is unlikely to change, the Waterfall model is suitable. However, if there is an expectation of future modifications based on client feedback, the Agile model, with its flexibility, becomes the preferred approach.

The history of DevOps

Khalil Chaymae — Sat, 11 Nov 2023 07:22:52 +0000

Why this post?

This article is about the history of DevOps. I'll talk about all the people who gave birth to DevOps, and where and why the history of DevOps began.
If you want to get into this field it's important to khow the history of DevOps, and understand why DevOps?

The history of DevOps

Let start by the year 2003, Google hired Ben Treynor to lead engineers in production, separate from development. The new position for these engineers is called SRE (Site Reliability Engineering).
Her primary responsibility is to maintain uptime of services provided by Google, while working closely with developers to ensure that customers' operations are not disrupted by any outage by Google resulting in lost sales of their core products. Although the term had not yet been coined, SREs were the first true practitioners of what is now known as the “DevOps” philosophy.

SRE: Site reliability engineering is a set of principles and practices that applies aspects of software engineering to IT infrastructure and operations. SRE claims to create highly reliable and scalable software systems. Although they are closely related, SRE is slightly different from DevOps.(Wikipedia)

In 2007/2008 Patrick Debois, a Belgian project manager and agile practitioner, accepted a contract with the Belgian government to support the migration of its data center and was responsible for testing. His responsibilities require him to manage activities and relationships between the application development team and the operations team (servers, network, and database). The experience and frustration of a lack of consistency between the application approach and the infrastructure approach led to Patrick Debois becoming dissatisfied. His desire for a better way would soon be put into action.

In 2008 at an Agile conference in Toronto (Canada), a man named Andrew Shafer tried to organize a session called "Agile Infrastructure." When Patrick showed up for the meeting, he was the only one there, but Andrew received so many negative comments that he didn't show up for his own meeting. However, Patrick was there leading a session called "Using Scrum and Agile Practices in a Business Context" and he was so excited that others shared his frustration that he found himself in the conference hallway Andrew and had a long discussion that made me realize there must be others out there who want to discuss an issue that seems so pervasive and systemic.

They then formed a focus group to allow others to share ideas on how to bridge the gap between the development phase and subsequent operations. Their discussions and sharing of ideas with others promoted the concept of “Agile Systems Management.” That same year, Debois and Shafer established a group of agile systems administrators at Google, but with limited success.

In 2009, the birth of DevOps: Flickr's senior vice president of technical operations John Allspaw, and director of engineering Paul Hammond, leveraged their experience managing uptime at the world's largest photo-sharing site. They noticed that the operations team, responsible for managing the servers, and the development team, responsible for writing the code, always seemed to be at odds. The proposed solution, they said, was to hire "operators(ops) who think like developers(dev)" and "developers(dev) who think like operators(ops)."

The two Flickr employees gave a now famous presentation translated into French as “10+ déploiements par jour : coopération Dev et Ops à Flickr”. The presentation had an air of drama, as Allspaw and Hammond role-played the contentious interaction between development and operations representatives during a typical software deployment, as well as all the blame that occurs, such as: "It's not my code, it's your machines!" or " It’s not my machines, it’s your code!". Their presentation showed that the only rational way forward is for application development and operations activities to be transparent and fully integrated.
Over time, this presentation acquired legendary status. They proposed unifying development and operations into an automated infrastructure with a common version controller, including one-step build and deployment. At this time, DevOps was born, but it didn't have a name yet.

October 2009 – Present: Popularization of the term “DevOps”
Debois did not attend the conference presented by two Flickr employees in person, but chose to watch via video stream. Inspired, he decided to host his own conference called "DevOpsDays". To promote the conference on Twitter, he used the hashtag "DevOps" as an abbreviation for the words "development" and "operations." This soon became the name of the movement Allspaw and Hammond first expressed during the conference.
DevOpsDays begins in Belgium. The event will be held in Australia and the United States next year... As time goes by, more and more DevOpsDays are being held in different countries and cities around the world. There, developers and operations experts come together to discuss automation, testing, security, and the organizational culture needed to avoid premature conflicts. The personal meetings influenced more and more people about DevOps and eventually became an independent grassroots movement. At this point, the term "DevOps" officially entered the history books.

Conclusion

the term DevOps consists of the words "Dev" (development) and "Ops" (operations), and we can say that there are two teams here. The role of operations in business enablement is to create an environment in which all aspects of an organization work together smoothly to achieve the organization's goals. This includes a combination of efficient processes, effective technology and infrastructure, risk management, customer satisfaction, cost control, and the ability to adapt and expand as needed. Development teams play a critical role in enabling your business by creating and maintaining high-quality solutions. High-quality software that meets the needs of businesses and their customers.
In a DevOps culture, the collaboration between development and operations is key to achieving agility, speed, and reliability in delivering software solutions.

Deploy a full-stack application(Angular-Laravel-Mongodb Atlas) on AWS.

Khalil Chaymae — Sun, 01 Oct 2023 20:06:26 +0000

Introduction
Welcome to the comprehensive guide on deploying an Angular, Laravel, MongoDB Atlas application on AWS (Amazon Web Services). This documentation is focused on helping you understand the step-by-step process of deploying our application stack on AWS infrastructure. By following these instructions, you will be able to host and run your application securely and efficiently.

Project Overview
Our project is a basic web application designed to help users manage their to-do tasks efficiently. It combines a minimalistic user interface with the reliability of Angular, Laravel, MongoDB Atlas, and AWS. Here's a brief overview of the core components:

Angular: Angular powers the front-end of our application, enabling dynamic and responsive user interfaces. It offers a simple and intuitive way to manage your to-do tasks.
Laravel: Laravel serves as the back-end of our application, handling task creation, updates, and deletions. It provides a user-friendly API for interacting with the to-do list.
MongoDB Atlas: MongoDB Atlas is our database solution. It stores and retrieves task data securely, ensuring that your to-do list is always available and up to date.
AWS (Amazon Web Services): AWS hosts and deploys our application. It guarantees scalability, reliability, and security, ensuring you can access your to-do list from anywhere.

Prerequisites
Before we dive into the deployment process, make sure you have the following prerequisites in place:

An AWS account with administrative privileges.
An Angular front-end application. This is the repository of the Angular project I used in this guide: https://github.com/Chaymae-Khl/ToDoList--Angular-Laravel-MongoDb--FRONTEND-.git .
A Laravel back-end application, this is the repository of the Laravel project I used in this guide: https://github.com/Chaymae-Khl/ToDoList-Laravel-MongodbAtlas--BackEnd.git .
A MongoDB Atlas cluster with your application's database.

Let's get started !!!

Step 1: AWS account

Create an AWS account : You can create an account via this link https://portal.aws.amazon.com/billing/signup#/start/email .
Enter you credit cart informations (We will use a free-tier product, so you won't be charged).

Step2: MongoDb atlas account

create MongoDb atlas account You can create an account via this link https://account.mongodb.com/account/register .
After entering your account information:

Select the free cluster and your provider (AWS) and change the cluster name if you want: (You have 512 MB of data size available to use in the free mode)

Create the user:

And voilà, your MongoDB database is ready:

Step3: Connect the back-end with Mongodb Atlas

Click the "Connect" button to obtain the connection string:

Click on Drivers:

In your .env file, update the DB_DNS link to the MongoDB Atlas connection string.

PROBLEM !!!
In this step, I encountered a connectivity issue. To resolve it temporarily, we added an IP address to the access list. However, it's essential to remove this entry later, as it's not recommended to grant access to our database for everyone.

Step4: Deploying the back-end (Laravel)
After confirming that the connection between the back-end and MongoDB Atlas works locally, you can proceed to deploy your application on AWS.

First, we need to compress our application files (ZIP)

So, before creating our environment, we need to create two things: the role and the EC2 key pair that we are going to use in the creation of our environment.

1- IAM role:

An IAM (Identity and Access Management) role in AWS (Amazon Web Services) is a secure and flexible way to delegate permissions to resources within your AWS environment used to grant temporary permissions to perform actions on AWS resources.

To create a IAM role:

Search for IAM service:

Click Roles > “ Create role ” button:

Select the Use case of the account:

Click the “ next “ button.
Now we choose the permisions : AWSElasticBeanstalkWebTier AWSElasticBeanstalkWorkerTier AWSElasticBeanstalkMulticontainerDocker

Enter the name of the role:

Click “create role” button.

2- EC2 key pair:

An EC2 key pair in AWS (Amazon Web Services) is a security credential used to securely authenticate and access virtual instances, specifically Amazon Elastic Compute Cloud (EC2) instances.

To create a key pair:

click the “Create key pair” button:

Enter the name of the key pair > click the “create key pair” button:
After that, a .pem file will be downloaded, and we will use it to connect with the instance.

In AWS search for ‘ elastic beanstalk ‘ service: Amazon Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS.

Now we are going to create our environment.

Enter the application name and the domain:

Select the PHP platform: When you select a platform in AWS Elastic Beanstalk, you are choosing the runtime environment for your application.

Here, we need to upload our zipped Laravel folder:

Click the “Next “ button.
In this step, select the role and the profile based on the permissions required and also choose the EC2 key pair that allows us to connect with the instance (We have already created the appropriate role and EC2 key at the beginning of this step).

Keep clicking "Next" until you reach this step. Fill the document root with "/public " > Next.

Click the “ Submit ” button.

After a few minutes, we can see that our application has been created successfully, and the health of the environment is "OK".

To check that the back-end works you can test in Postman the routes: EX:

PROBLEMS !!!
In this step I encountered two problems:

Problem 1:

I encountered an issue with the driver that is not available in the application's instance, causing the application to not work automatically. This is the opportunity to connect to our instance and make the necessary changes.
The first thing we need is Ubuntu because I encountered issues with Windows, and it didn't work properly. To avoid any problems, you can install Ubuntu from the Microsoft Store and use it for this process.
If you remember, during the process of creating the EC2 key pair, a .pem file was downloaded. We will now use this file.
After installing Ubuntu, place the file in the Ubuntu root directory Ubuntu\root.
Then, open the Ubuntu terminal.
In AWS search for EC2 > instances.

Select you instance and click the “Connect” button:

Now we can install the mongodb driver

Type the following command to install it, and it will take a few minutes.

Then, you have to restart the Nginx server using the following command:

To check if MongoDB has been installed successfully, type the following command and search for "mongodb", This command will list all installed PHP extensions, and if MongoDB is installed, you should see "mongodb" in the output.

Now that we have installed the MongoDB driver, we have resolved the driver problem, and your Laravel application should be able to connect to MongoDB without any issues.

Problem 2:

Another issue I encountered was related to route accessibility. It seems that not all routes in the project are accessible.
To resolve this issue, we need to make modifications to a configuration file in the Nginx server. This file likely controls how incoming requests are routed and processed, and making adjustments to it can help ensure that all routes in the project are accessible as intended.
You can use the following command to open the Nginx configuration file for editing:

Add the following lines > Ctrl+s > Ctrl+x

Restart the server :

And now the routes problem is solved.

Finally, remember to remove the 0.0.0.0/0 IP address from the MongoDB Atlas access list and replace it with the IP address of your instance to enhance security.
This ensures that only your AWS instance can access your MongoDB Atlas database.
Go to your AWS EC2 instances and copy the public IP address of your deployed instance

Now, go back to MongoDB Atlas and update your access list to include the public IP address of your AWS instance, which you copied in the previous step. This ensures that your database is accessible only from your AWS instance.

Congratulations! You have successfully deployed your back-end application.

-Step5: Deploying the Front-end

After deploying our back-end project and confirming that it works seamlessly with MongoDB Atlas, there are a few changes we need to make to our Angular project:
First, we need to update the API URL in all the services to reflect the domain where the back-end is deployed.
Make sure to update all the URL in your project. EX:

After updating all the URLs, we need to build our Angular project. Run the following command:

After running the build command, you'll notice that a new folder has been created: /dist
We're going to use these files in the deployment process.

Now, go to the AWS service, and this time, we're going to use a service named S3.

click on “Create bucket” button:

Enter the bucket name > Create bucket:

Uncheck 'Block all public access'.

Then click 'Create bucket' button.
Click on the bucket that you just created:

Click on “Upload” button:

Click on “Add files” button:

Now upload your files.

Click on “Upload” button:

Now after we uploaded our files click on your bucket.
Then click Propreties.

Edit the Static website hosting:

Change Static website hosting to enable:

then click 'save changes' button.
Now, it's time to make some changes to the permissions:

Let's first define what a policy means in the context of S3:
A policy is a JSON (JavaScript Object Notation) document that defines permissions and access control rules for S3 buckets and objects. S3 policies are used to specify who can access your S3 resources, what actions they can perform (e.g., read, write, delete), and under what conditions those actions are allowed or denied.

After defining the policy, it's time to make edits to the bucket policy:

Now, add a new policy:

Click on the 'Save changes' button.
We are done we can access our application via internet.
To access the application click on your bucket name > Properties

DEV Community: Khalil Chaymae

Create a container using the Ubuntu image in Docker.

AGILE VS WATERFULL methodology

What is a methodology ??

WaterFull methodology :

Agile methodology:

In which scenarios should I choose the Waterfall model, and when is it more appropriate to opt for Agile?

The history of DevOps

Why this post?

The history of DevOps

Conclusion

Deploy a full-stack application(Angular-Laravel-Mongodb Atlas) on AWS.

Congratulations! You have successfully deployed your back-end application.

Congratulations! You have successfully deployed your FullStack application.