DEV Community: Ahmed A. Elkhalifa

From Ubuntu + VSCode to Arch + Neovim

Ahmed A. Elkhalifa — Mon, 29 Jan 2024 07:15:00 +0000

There are various motivations for ditching Ubuntu for Arch Linux, whether it's the thrill of distro hopping or the noble quest to vanquish bloatware. Having made the leap myself an year ago, I aim to guide potential Arch adventurers through this process.

Why?

Before you embark on the Arch Linux journey, ask yourself "why?" Your reason will fuel your determination when things get tricky. For me, the switch stemmed from three desires:

A better understanding of my operating system, I wanted to know how packages on my system work together to give me my final experience.
More skills with Linux, as my job envolves working a lot with Linux servers, I wanted to have more skills with bare-skin Linux systems.
A lighter system, my 4-years Ubuntu installation was now idling at 1.1GB RAM usage with tens of packages that I don't even remember installing or ever using and I felt that needed to change.

The following parts of this article are steps crafted out from my personal experience, some of them I've tried and worked best for me, some are things I wish I had done, follow whatever makes sense to you, in the end this is your personal journey.

Step 1: Getting your feet wet

Going ahead and installing Arch Linux on your main PC right away is of course a foolish move, you'll need to install Arch Linux on a virtual machine first, and I recommend following the Offical Arch Linux Installation Guide , the process might seem tidious at first, specially that it's a terminal-based installation process rather than a graphical one, but following this process you will make you understand a lot about the underlying parts of the Linux operating system.

I recommend that you install Arch Linux 2 or 3 times on a virtual machine first, taking notes each time of the packages you installed and the problems you faced.

I would also recommend installing and trying different desktop environments during this phase, this will help you understand how different DEs work and you will find what suits you better.

At this point, install the programs and packages you are already familiar with, try changing only the parts that make your operating system (desktop environments, wifi control interface, etc) but keep using the same programs (browser, text editor, etc) you're already using, this way you can test your workflow against the amalgamation of an OS that you have made.

Start shifting some of your workload from your main PC to your Arch Linux virtual machine, I recommend you start with simple tasks like browsing the web or coding side projects. Move at a pace that suits you, and when you feel accustomed to your OS then take a leap of faith and install Arch Linux on your rig.

Step 2: Harnessing the power of Linux

Linux, or I should say GNU/Linux is a very powerful operating system, and it has a lot of "built-in" features and tools that you can use, since you've come to Arch Linux land, you might as well dedicate some time into learning how to use the operating system to a good extend.

You've probably used the terminal a lot by now, but if you're using the terminal only when needed or when there is no other option, I would recommend starting to use it more, start using the terminal for file managment, use the basic commands ls, cd, mkdir, touch, rm, mv and cp as your main method of dealing with files, also start using commands like grep and find for searching, you can keep a GUI file explorer just in case you get stuck, but try to rely on the terminal more, and you might be intersted to read about the Linux File Permissions as well.

I would also recommend learning more about systemd and how you may use it to create your own services.

Linux comes bundled with great utilities that might come in handy to do a lot of simple tasks that occurs a lot in one's workflow, for example:

You might have a csv file called data.csv that contains data about the employees at your company: ID, Name, Department, Deductions and Salary, and you want to generate another file called processed.csv that contains only the ID and Total in which Total is the calculated amount from the equation Salary - Deductions. You could do this manually using a spread sheet program, or even better by writing a python script since this would be a monthly problem, both ways work, but if you know your Linux, you can solve this problem with a single line command:

$ awk -F',' 'NR == 1 {print "ID,Total"} NR != 1 {print $1 "," $5-$4}' data.csv > processed.csv

Although this might seem bizarre, it's a really simple Awk command that you yourself would be able to fully understand after watching a 20 minute video on YouTube, and what's great about it (beside it's literally one line) is that it can be ran on virtually any Linux machine without installing any new packages or dependencies!

Another great example of using Linux tools is dealing with baseUrl in CI/CD pipelines. If you're responsible of making a CI/CD pipeline for a web project that involve dealing with the website running on sub-path you may find yourself in a position to deal with a baseUrl or a basePath variable that could be different in production than in the developers' local environment, and you might solve this issue in serveral ways that may include setting a policy to never checkout the file containing the baseUrl variable (Spoiler alert: someone will) or you might set a script to change the variable in production, another easy way to do so is using the Linux sed command to do an inline change to the file during the CI/CD pipeline, something like this:

$ sed -i "s;baseUrl='/';baseUrl='/some-path';" index.html

There's a lot of amazing Linux commands and utilities, I recommend exploring them as they might come in handy.

I recommend reading the Linux man-pages and the Arch Wiki as those are two of the greatest sources of Linux knowledge ever, I've personally learned more from reading the Arch Wiki for one day than I have learned from googling my way through Ubuntu for four years.

Step 3: The Dungeons of Vim

Now a few weeks have passed since you switched to Arch Linux and things are looking great, maybe it is time to start using the ultimate text editor.. Vim (or more precisely Neovim).

The transition from a text editor like VS Code to Vim might seem hard, and rightfully it is, but it's not imposible!

I would recommend a few steps that will help you make this transition as smoothly as possible:

Start with bare-skin Vim: don't install Neovim yet, start by learning the basics of Vim specially Vim Motions, I recommend checking out the vimtutor to get used to everything.

Moving away from the GUI: A lot of people will recommend using your text editor (aka VS Code) with a vim motions plugin to learn vim motions better, while this is true, vim has a lot more to offer than just motions, so I would recommend using vim to write readme files or for taking notes just to get familiar with the entire program.

After a week or so from using vim you will feel great! you will have this burning desire to use vim motions everywhere! on your browser, on your email client, just everywhere!. Althought some people seek that path (Looking at you ThePrimeagen) I would recommend you refrain from it, at the end you are propably the "Tech-support guy" of your family and friends, so you still need to know how to use a computer like a normal human being.

When you feel that the only thing holding you from using vim as your primary text editor is the tooling (auto-compelete, error messages, etc.) that would be the perfect time to sudo pacman -Syu neovim.

Neovim is basically Vim on steroids. To start with Neovim some people might recommend using pre-made configuration like NvChad or LazyVim, but I would recommend the opposite, start configuring Neovim on your own, you will need a little bit of Lua and a tutorial, it might feel overwhelming at first, but don't worry, it gets easier with time and you will learn a lot throughout the process.

One great tutorial on how to setup NeoVim is this one by ThePrimeagen, I highly recommend that you watch it.

After you setup Neovim the way you like it, start moving all your work to NeoVim, it might be a little bit difficult at first but once you get the grip of it you will wonder how have you been living without it before.

Epilogue

This journey is not an easy one, it took me one year to feel comfortable about my system and setup, it can take you longer or shorter depending on how you like this system to be, but always remember that you need to make it yours, and that's the only thing that matters.

x64 Assembly: Multithreading from Scratch Part 2: Threads

Ahmed A. Elkhalifa — Thu, 16 Mar 2023 23:36:02 +0000

In Part 1 of this series we have looked into how to use fork system call to spawn a child process and branch out on the child process to do a different code path. In this part we will look into how we can implement a more functional way to do multithreading in assembly.

Goal

We want to use any function/subroutine in our assembly code as a thread, meaning that we want a way to call a function and this function will run on a different thread, then we need a way to wait (on the parent process) for the threads we create.

Implementation

We will create a file lib/thread.asm that will have two functions:

thread_run: It will take a pointer to the code we want to execute (stored in rax) and then it will pass along the registers rdi, rsi, rdx and r8 unchanged to the function now running on the child thread it will create. This function will call fork and then on the child thread it will jump to the code pointed at by rax, on the parent it will return the PID of the child process in rax.
thread_wait: This function takes a single argument in rax which is a PID of a child process, it will wait for that child process to finish executing then it returns the exit code of that child process in rax.

`thread_run`

# lib/thread.asm

.intel_syntax
.section .text

# thread_run
# A function to start running the given code on a child process
#
# Arguments:
#   rax: Pointer to function(label)
#   rdi, rsi, rdx, rcx, r8 : The arguments to the function
#
# Returns:
#   rax: Child process id
#
.global thread_run
thread_run:
    push %rax # Push rax value to the stack

    # Fork this process
    mov %rax, 0x39
    syscall

    cmp %rax, 0x00 # Compare the returned PID
    mov %r10, %rax # Store the PID in r10 temporarily
    pop %rax # Get back rax value (Function pointer)
    je _invoke # Jump if this is the child process

    # If this is the parent process then return 
    mov %rax, %r10 # Restore the PID
    ret

_invoke:
    # Jump to the pointer of the function
    call %rax

    # Safe exit
    mov %rax, 0x3c
    mov %rdi, 0x00
    syscall

In the above code, the function starts by storing (pushing) the pointer that is in rax to the stack because we need the rax register to make a fork system call, then we compare the return of fork to zero and store the PID (the current value of rax) in r10 register temporarly, and put back the function pointer in rax register and jump conditionally to the _invoke function/subroutine if the value of the earliy comparison is correct, other-wise we restore the PID in rax and return. _invoke subroutine will call the function in the address stored in rax and then exit safetly with the exit syscall.

`thread_wait`

# lib/thread.asm

...

# thread_wait
# Wait for a process to exit
#
# Arguments: 
#   rax: Process PID
#
# Returns:
#   rax: Exit code
#
.global thread_wait
thread_wait:
    # Allocate space in the stack to store the exit code
    sub %rsp, 4

    mov %rdi, %rax # Move the PID to %rdi for wait4 syscall
    mov %rax, 0x3d # wait4 syscall
    mov %rsi, %rsp # Pointer to the exit code space
    mov %rdx, 0x00 # Flags
    mov %r10, 0x00 # NULL pointer
    syscall

    # Store the exit code in EAX (4 byte value of rax)
    mov %eax, [%rsp]
    add %rsp, 4

    ret

In the above code we start by allocating 4 bytes of memory on the stack, then we call the wait4 system call, we basically give it the PID of the child process in rdi and a pointer to 4 bytes in memory to store the exit value of the child process that exited (We give it the 4 bytes we just allocated on the stack). After wait4 syscall returns, we get the return value from the stack and deallocate that memory from the stack.

NOTE: The last step could be achived using pop DWORD %rax but for some reason using gas it didn't want to assemble, but I assume it will work fine on MASM or another assembler.

Assembly

Now we will assemble this code the same way we did with util.asm using the following commad:

$ as lib/thread.asm -o thread.o

If eveything works fine we will now have a thread.o file that we will link our code with.

Driver Code

To demonstrate how these two functions work, we will create a new directory hello_threads in the root of our project and put a main.asm file inside of it.

In this file we will write a program that will execute a thread to run the print function we wrote in util.asm last time and wait for the thread to finish executing, and then print from the main (parent) process.
Then the program will execute another thread with the print function and continue running the main (parent) process without waiting.

# hello_threads/main.asm

.global _start
.intel_syntax
.section .text

# The external functions we need
.extern thread_run
.extern thread_wait
.extern print

_start:
    # Create a thread
    call _log
    lea %rax, [%rip + print]
    lea %rdi, [%rip + thread_msg]
    mov %rsi, OFFSET thread_msg_len
    call thread_run

    # Wait for the process (PID is in rax) then print
    call thread_wait
    call _pmsg

    # Create a thread
    call _log
    lea %rax, [%rip + print]
    lea %rdi, [%rip + thread2_msg]
    mov %rsi, OFFSET thread2_msg_len
    call thread_run

    # Print without waiting
    call _pmsg

    # Exit
    jmp _exit


_pmsg:
    # Print 'parent_msg'
    lea %rdi, [%rip + parent_msg]
    mov %rsi, OFFSET parent_msg_len
    call print
    ret

_log:
    # Print 'log_msg'
    lea %rdi, [%rip + log_msg]
    mov %rsi, OFFSET log_msg_len
    call print
    ret

_exit:
    # Exit safetly with status code 0
    mov %rax, 0x3c
    mov %rdi, 0x00
    syscall

.section .data
    log_msg:
        .ascii "\nCreating a thread..\n" # 20
        log_msg_len = . - log_msg
    thread_msg:
        .ascii "Hello from thread 1!\n" #19
        thread_msg_len = . - thread_msg
    thread2_msg:
        .ascii "Hello from thread 2!\n" #19
        thread2_msg_len = . - thread2_msg
    parent_msg:
        .ascii "Hello from parent!!\n" #20
        parent_msg_len = . - parent_msg

Now we assemble our code and link the resulting object file with both lib/util.o and lib/thread.o with the following commads:

$ as hello_threads/main.asm -o hello_threads/hello_threads.o
$ ld hello_threads/hello_threads.o lib/util.o lib/thread.o -o hello_threads/hello_threads.elf -nostdlib

If everything goes well, we should now have a hello_threads.elf in hello_threads directory, if we execute the file we should see an output similar to this:

Creating a thread..
Hello from thread 1!
Hello from parent!!

Creating a thread..
Hello from parent!!
Hello from thread 2!

Notice how the first thread executes before the main (parent) thread due to us using the thread_wait function that we defined earlier. But in the second theard case it is different, the parent executes first -for most of the time- since it does not have to wait for the thread to finish executing.

Now that we have a functional way to spwan and wait for threads we will need a way for threads to communicate and share data with each other, so in the next part we will look into how we can allocate and share memory between threads.

The code is available on the Github repository if you want to check it out.

x64 Assembly: Multithreading from Scratch Part 1: Hello World!

Ahmed A. Elkhalifa — Wed, 15 Mar 2023 14:21:13 +0000

Content of The Series

In this series of tutorials we will look into how to implement multithreading techniques in x86_64 Assembly from scratch without using the standard library.

Part 1: Hello World! from Scratch
Writing a simple program to print to the standard output from two different processes.

Part 2: Threads
Implementing a functional way of creating and waiting for threads.

Part 3: Shared Memory
Implementing memory managment functions and showing how we can share memory between threads.

Part 4: Mutexes
Implementing a mutex to control memory access between threads.

Prerequisites

To follow along with this tutorial you wil need a basic knowledge in assembly. You will also need a linux environment as we will implement everything from scratch using only the kernel system calls.

Tools

In this tutorial I'm using the GNU assembler gas with intel syntax along the the GNU linker.

Using other assemblers like MASM or NASM should be fine, just make sure to review the differences in syntax between the code shown in this series of tutorials with the code you intend to write, take a look at this link.

Hello, World! from scratch

Since we won't be linking against the standard library (Linking with -nostdlib) we will not have access to commonly used functions like printf or malloc and will have to implement them from scratch using the x86_64 linux system calls.

Project structure

- Project Folder
  |
  |-- lib/   # The directory for our reusable code
  |   |
  |   |-- util.asm   # utilities (print, malloc, etc..)
  |   |....
  |
  |-- hello_world/
      |
      | -- main.asm # Our code for Part 1

Print function

Now we will need to implement a simple function to print to the standard output STDOUT using the write system call.

Our print function will take 2 arguments: ptr and len

ptr: The address of the string (passed in register rdi)
len: The length of the string (passed in register rsi)

# lib/util.asm


.intel_syntax
.section .text

# print function that takes (ptr, len)
# as arguments (rdi, rsi)
.global print
print:
    mov %rdx, %rsi # move the length to rdx
    mov %rsi, %rdi # move the pointer (rdi) to rsi
    mov %rax, 0x01 # write syscall on x64 Linux
    mov %rdi, 0x01 # STDOUT file descriptor
    syscall
    ret

This function that we defined above takes 2 arguments using the rdi and rsi registers then rearrange the registers to call the write syscall on the STDOUT file descriptor.

Now lets assemble it with the following command:

$ as lib/util.asm -o lib/util.o

Now we should have an object file lib/util.o that we will link against to have access to our utility functions.

`fork` System Call

Throughout this series we will be making heavy use of the fork system call which basically tell the OS to create a child process of the current process, this child process is an exact copy of the parent and it will start executing from the next instruction of the parent.

Writing the Code

# hello_world/main.asm


.intel_syntax
.global _start
.section .text

.extern print # Use our print function

_start:
    # Call the 'fork' syscall
    mov %rax, 0x39 # fork syscall on x64 Linux
    syscall
    cmp %rax, 0 # 'fork' will return 0 to the child process
    je _child

_parent:
    # Print 'Hello from parent!'
    lea %rdi, [%rip + msg1]
    mov %rsi, OFFSET msg1len
    call print
    jmp _exit

_child:
    # Print 'Hello from child!'
    lea %rdi, [%rip + msg2]
    mov %rsi, OFFSET msg2len
    call print

_exit:
    # Call the 'exit' syscall
    mov %rax, 0x3c # exit syscall on x64 Linux
    mov %rdi, 0x0 # Exit code
    syscall

.section .data
msg1:
    .ascii "Hello from parent!\n"
    msg1len = . - msg1
msg2:
    .ascii "Hello from child!\n"
    msg2len = . - msg2

In the code above we have 2 different functions: _parent which will print Hello from parent! and exit, and function _child which will print Hello from child! and exit. On the main function _start we will make a fork system call which will create a copy of the current process and store a value in the register rax, this value will be 0 on the child process and will be the PID of the child process on the parent, so we will make use of this information. We will compare the value of register rax to zero, if it is zero we will jump to the _child function, if not, we will continue to execute the _parent function.

Assembling and Linking

We will assemble the code and link it with util.o object file containing the print function without linking the standard library using the following commads:

$ as hello_world/main.asm -o hello_world/hello_world.o
$ ld hello_world/hello_world.o lib/util.o -o hello_world/hello_world.elf -nostdlib

If everything goes well we should have an executable hello_world/hello_world.elf and if we execute it we should see the output:

$ ./hello_world/hello_world.elf
Hello from parent!
Hello from child!
$

Great! we have successfully written an x86_64 assembly program to execute 2 deifferent code pieces from two different threads. Next, we will look into how to implement a more functional solution to make it easy create and wait for threads.

The code for this tutorial is available in this repository. The code repository will be updated with every new part of the series.

Node.js and Docker: Write, Build and Publish

Ahmed A. Elkhalifa — Sat, 22 Jan 2022 15:01:12 +0000

Overview

In this tutorial we aim to create a simple Node.js app with Express.js and containerize it with Docker then publish it to Docker Hub.

NOTE: This will be a practical tutorial so I will not be explaining any concepts such as Node.js, containerization or Docker. And I will also assume you already have node and docker installed on your machine. But if you want me to write an article explaining those concepts, let me know in the comments.

Sections

Write the Node.js App
Containerize the App with Docker
Publish the Image to Docker Hub

1. Write the Node.js App

We will first create a simple Node js app that we will then work with. Follow these steps to create the app:

1. Create a new directory for the project
Create a new directory for the project with whatever name you like

$ mkdir nodejs_docker_tutorial

and cd into it

$ cd nodejs_docker_tutorial

2. Initialize the project
I'm gonna be using npm but you can use whatever package manager that suits you. To initialize the project with npm run:

$ npm init

Fill out the information and set entry point to be src/app.js
the final package.json should be something like

{
  "name": "nodejs_docker_tutorial",
  "version": "1.0.0",
  "description": "",
  "main": "src/app.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

3. Install the packages
We are going to need these packages:
express, cors and (as an optional dev dependency) nodemon
run:

$ npm i express cors
$ npm i -D nodemon # Optional

4. Create the files and directories
Create the following files and directories so that the project tree should look like:

.
├── package.json
├── package-lock.json
└── src
    ├── app.js
    └── routes
        └── home.js

5. Use nodemon to watch for changes (Optional)
Installing and using nodemon is optional and I've included it in the tutorial just as an example to simulate a real-life scenario.
In the scripts section in package.json add the dev script as follows:

...
"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "dev": "nodemon src/app.js"
  },
...

and now in a terminal session you can run:

$ npm run dev

and it will watch for changes in your source code and rerun the app every time a change is made

6. Write the code
Now we are going to write our actual application.
The goal is to make a simple web server that listens on port 8080 and have 2 endpoints:

GET /
Responses:
200 Hello from Docker!

GET /greetings/:name
Responses:
200 Hello, {name}!

So now in your favorite text editor edit the source code as follows:

The source code for src/app.js will be:

const express = require('express')
const cors = require('cors')
const app = express()

// Use CORS with default options to allow all origins
app.use(cors())

// Import the home router
const homeRouter = require('./routes/home')

// Use the home router
app.use('/', homeRouter)

// Define the port to listen on
const port = 8080

// Start the server and log a message after it starts
app.listen(port, 
    () => console.log(`Server listening on port: ${port}`)
)

and for src/routes/home.js it will be:

const express = require('express')

// Create the router
const router = express.Router()

// Configure the endpoint for the router
router
    .get('/', (req, res) => res.send('Hello from Docker!'))
    .get('/greetings/:name',
            (req, res) => res.send(`Hello, ${req.params.name}`))

// Export the router
module.exports = router

7. Test the app
Now we are going to test if our code works or not.

If you are using nodemon just head to http://localhost:8080
If you are not using nodemon just run:

$ node src/app.js

and then head to http://localhost:8080

You should see a web page as follows:

And if you go to http://localhost:8080/greetings/Ahmed you will see something like:

Congrats! Now the app is done and we can move to the docker stuff!

2. Containerize the App with Docker

Now that our app is ready we can use Docker to create an image of our app.
To create an image for your app follow these steps:

1. Stop the running node app
First thing to avoid port conflicts later on, we need to stop the app for now, use Ctrl+C on the terminal session where you started your app.

2. Create a Dockerfile
In the root directory of the project create a file named Dockerfile, for example you can run:

$ touch Dockerfile

3. Dockerfile code
In the Dockerfile you just created put the following code:

# Base image
FROM node:alpine

# The working directory inside the container
WORKDIR /App

# Copy the package.json file
COPY package.json package.json

# Install the packages for production environment
RUN npm i --production --omit dev

# Copy the source files
COPY src/ src/

# The main entry point of the container
CMD [ "node", "src/app.js" ]

The Dockerfile is divided into steps, each line represents a step (lines starting with # are comments)
So I'll explain each line/step:

Step 1: Import base image

FROM node:alpine

We select the base image to use for the custom image we want to create, here we are using the Official Node Image with the alpine tag which will basically import the Alpine Linux image with Node installed in it. I'm using Alpine image just because it is lightweight, but you can use any other image you like and you can specify what version of node you want, for example you can use:

FROM node:14.18

To use node version 14.18.

Step 2: Select the working directory

WORKDIR /App

We specify a directory -inside the container- to put our app inside of it, you can use anything you like.

Step 3: Copy package.json to our working directory

COPY package.json package.json

We will copy our package.json file to the working directory we specified in the above step. Note that you don't need to navigate or write the path of the working directory after you specified it with WORKDIR instruction.

Step 4: Instal node modules for production

RUN npm i --production --omit dev

This command will basically run npm install with the --production and --omit dev flags. You can use any other flags but this is what I personally use for production apps.

Step 5: Copy the source files to the working directory

COPY src/ src/

Now we will copy out source code files to the working directory we specified on Step 2.

Step 6: Run the node app as the entry point of the image

CMD [ "node", "src/app.js" ]

This is the command that will be run when we spin up a container with our image and we just want to run node src/app.js.

So that's it, we are done with our Dockerfile.

2. Build the Docker image
Now we want to build the actual image that we will use to spin up containers of our app.
In the terminal run:

$ docker build .

NOTE: You might need to run the docker commands with sudo if you haven't done the Docker Post-installation Steps

After the command is done you should see something like:

...
Successfully built 33482f9f2921

3. Get the Image ID
We will need the Image ID so we can use it since we didn't specify any tags for it. You can copy the ID from the above docker build output on your terminal or you can list all the images you have using:

$ docker image list

The output will be something like:

REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
<none>       <none>    33482f9f2921   1 minute ago   177MB
...

Now copy the IMAGE ID.

4. Run a container with the new image
Now we can run a container to test our image, in the terminal run:

$ docker run -d -p 8080:8080 <IMAGE_ID>

Replace <IMAGE_ID> with the ID of your image.
The flag -d is used to run the container in Detached Mode(in the background).
The flag -p will expose a port from the container on the host machine. It uses the syntax -p hostPort:containerPort.
You can read more about these flags in the Docker Run Reference.

The output should be a hash, something like:

70f36364143abafd4ce2a4f338b20d97015fda400a0bcfd86fd819e86ee39752

It means that you are up and running. If you go to http://localhost:8080 you should find the app running!

5. Stop the container
You can stop the currently running container using the command:

$ docker stop <CONTAINER_ID>

Replace <CONTAINER_ID> with the output of the previous step or run:

$ docker ps

To get a list of the running containers and then copy the CONTAINER ID from the output.

Now we know our image is ready and we can publish it to a Container Registry to use it from anywhere we want!

3. Publish the Image to Docker Hub

Now we have completed developing our app and we built a Docker image of it, now we need a way to distribute/publish our image either publicly or privately.

Docker Hub is a Container Image Library or a Container Registry where people can push(publish) their images to repositories and make those repositories either public for anyone to view and pull(download) or private where only those authorized can view it or pull it to spin up containers.
We will be pushing our image to a public repository on Docker Hub where we can pull it and use it from anywhere.

To do that, follow these steps:

1. Create a Docker Hub account
If you don't already have an account go to hub.docker.com and create an account.
Note that your username on Docker Hub will be your namespace for your repositories, for example mine is ahmedwadod so my images will be ahmedwadod/image_name:tag

2. Create a repository
In your account home page click on Create Repository

Now fill out the details of your repository, we will be setting the visability to Public, if you set it to Private you are going to need to login with your credentials on Docker whenever you want to pull the image.

Now click Create and you will have your repository set to go.

3. Tagging the image
Now we need to rebuild our image with the appropriate tags, the tag for your image will be: YOUR_USERNAME/REPO_NAME:TAG for the :TAG we will use latest as it is the default. The :TAG can be used to when you want to upload different versions of your app for example it can be :v1.0 or :v2.0 or it can be used for different variants of the base image used, for example :v1.0-alpine or :v1.0-ubuntu.
In my case the tag will be: ahmedwadod/nodejs-docker-tutorial:latest

To build the image go to your project's root directory and in the terminal run:

$ docker build -t YOUR_USERNAME/REPO_NAME:TAG .

The output should be something like:

...
Successfully built 33482f9f2921
Successfully tagged ahmedwadod/nodejs-docker-tutorial:latest

4. Login to Docker Hub
Now to publish our image we need to first login into Docker Hub from the terminal, run:

$ docker login -u <YOUR_USERNAME>
Password: # Enter your password and press enter

The output will be:

Login Succeeded

5. Push the image to Docker Hub
Now all we have to do is push the image, run:

$ docker push YOUR_USERNAME/REPO_NAME:TAG

The output will be something like:

The push refers to repository [docker.io/ahmedwadod/nodejs-docker-tutorial]
a62d27597b40: Pushed 
c8b55b75e003: Pushed 
d6605a78d13e: Pushed 
86145b7dbdcb: Pushed 
25c4d12b64e7: Mounted from library/node 
1d454e07796f: Mounted from library/node 
970073eeaee3: Mounted from library/node 
8d3ac3489996: Mounted from library/node 
latest: digest: sha256:49d70d1032b3389b465db6691c7e402f146d366b71df9f2b2196301af86116c2 size: 1990

Now if you go to the repository in Docker Hub and then to the tags tab you will find the tag latest available.

6. Run the image from anywhere!
Now you can go to any server with docker installed on it and run:

$ docker run -d -p 8080:8080 YOUR_USERNAME/REPO_NAME:TAG

And it will spin up a container with your Node js App!

Closure

Now that you have containerized your app, you can deploy it. I will be posting in the future about deploying web apps with Dcoker, so follow me to stay tuned.

You can find this tutorial's code on my Github

If you have faced any problems with these steps, comment down below and I will try to help you fix it.

Thank you for reading.

DEV Community: Ahmed A. Elkhalifa

From Ubuntu + VSCode to Arch + Neovim

Why?

Step 1: Getting your feet wet

Step 2: Harnessing the power of Linux

Step 3: The Dungeons of Vim

Epilogue

x64 Assembly: Multithreading from Scratch Part 2: Threads

Goal

Implementation

thread_run

thread_wait

Assembly

Driver Code

x64 Assembly: Multithreading from Scratch Part 1: Hello World!

Content of The Series

Prerequisites

Tools

Hello, World! from scratch

Project structure

Print function

fork System Call

Writing the Code

Assembling and Linking

Node.js and Docker: Write, Build and Publish

Overview

Sections

1. Write the Node.js App

2. Containerize the App with Docker

3. Publish the Image to Docker Hub

Closure

`thread_run`

`thread_wait`

`fork` System Call