Unit testing is a critical component of modern software development, enabling developers to catch bugs and ensure that their code behaves as expected. If you're new to unit testing or looking to improve your existing workflow, this guide will help you get started with unit testing in Python. In this post, we'll walk through the steps required to configure a Python project for effective unit testing. We'll cover the tools and libraries needed, how to write and run tests. By the end of this post, you'll have the knowledge and skills you need to start writing and running unit tests in Python.

Table of contents

• Modules Used for Testing
• Tests Discovery & Tests Naming Conventions
• Commands to Run the Tests
• pytest Config File
• Setup Example
• Conclusion

Modules Used for Testing

There are several modules (packages/libraries) that can be used to write and run your tests with.

Test frameworks / Test runners

• Python's built-in module unittest:
  • Has built-in assertion and mocking APIs,
  • Compared to pytest it has a verbose assertion APIs,
  • No auto-discovery, you need to mark a folder as a module in order to be discovered,
  • No plugins support.
• Standalone module pytest (recommended):
  • Has built-in assertion and mocking APIs,
  • Simpler assertion APIs compared to unittest,
  • Auto-discovery of test modules,
  • Can run unittest tests (great to support legacy tests),
  • Supports plugins.

Both are good, but it depends on what you want to test, one module can be a better choice over the other depending on the what you’re testing.

For the sake of being future proof, I recommend going with pytest which is better than unittest when it comes to running tests whilst having a big list of plugins which makes it easier to mock third party modules (in unittest you need to mock a lot to make a third-party module fully mocked).

Tests Discovery & Tests Naming Conventions

Test files needs to be discovered in order to be tested (ran), and there is a difference between how unittest and pytest are discovering tests.

In unittest:

• Files needs to be in the same directory,
• If it’s in a nested folder, it needs to be a module (by adding a __init__.py file).
• Files' names needs to start with test_*.py (default),
• You can override this pattern using -p CLI flag.
• Test methods needs to start with the same pattern: test_*(self):,
• Inside each test file, you need to have a main method/function:

if __name__ == '__main__':
    unittest.main()

• Tests cases (test grouping) can be done via a class:

class MyFunctionalityTests(unittest.TestCase):

In pytest (recommended):

• Files doesn’t need to be in the same directory,
• Files' names should be prefixed or suffixed by test_*.py or *_test.py,
• Test methods needs to start with a prefix: test_*(): or test_*(self): (if inside a class test case),
• No need for a main method/function,
• Tests cases (test grouping) can be done via a class;

class TestMyFunctionality:

Commands to Run the Tests

In unittest:

python3 -m unittest file_name.py

In pytest:

pytest

More ways on how to invoke tests in pytest can be found here.

pytest Config File

To set some configurations for pytest runner, you can create a config file with different formats, but for the sake of simplicity use either .pytest.ini or pytest.ini.

A sample configuration file:

[pytest]
testpaths = src test

More on configuration options can be found here.

Setup Example

Finally to the setup example, we will start by creating the required files and content of each file:

Create a directory if you're setting a new project:

mkdir my-python-project

Create a main.py file:

touch main.py

def custom_sum(first_number, second_number):
    print(f'Summing {first_number} and {second_number}')
    return first_number + second_number

if __name__ == '__main__':
    print(custom_sum(1, 1))

Create a main_test.py file:

touch main_test.py

import builtins

from pytest_mock import MockerFixture
from main import custom_sum

class TestCustomSum:
    def test_should_sum_two_positive_numbers_correctly(self, mocker: MockerFixture):
	    # Arrange
        print_spy = mocker.spy(builtins, 'print')

		# Act
        result = custom_sum(1, 1)

		# Assert
        print_spy.assert_called_once_with('Summing 1 and 1')
        assert result == 2

Create a requirements.txt file (dependency file like package.json in JS/TS based projects):

touch requirements.txt

pytest==7.2.2
pytest-mock==3.10.0

Install dependencies:

python3 -m pip install -r requirements.txt

Run tests:

pytest

Conclusion

In this guide, we've covered the essential steps required to configure your Python project for effective unit testing. We started by introducing the modules commonly used for testing in Python and discussed the importance of adhering to naming conventions to make your tests easy to discover and maintain. We then covered the commands you'll need to run your tests and how to create a pytest configuration file to customize your testing environment. Finally, we provided an example of how to set up your project for testing using the popular pytest framework.

By following these guidelines, you can ensure that your Python code is thoroughly tested, helping to catch bugs early and ensure that your software behaves as expected. Remember, unit testing is a critical component of modern software development, and investing the time to learn how to do it effectively can pay dividends in the long run.

You can find the code of this post in this repository.

As always, I hope you learned something.

Found this useful? feel free to share it with your friends.

Join the newsletter from here to notify you of new posts and updates.

Like the post? consider buying us a coffee ❤️.

Learn how to mock environment variables in a NodeJs project while implementing Jest tests that depend on environmental variables.

Table of contents

• What Is process.env?
• Why Mock process.env?
• Mock process.env in Jest Tests
• Conclusion

What Is process.env?

In NodeJs, process.env is basically a global object that holds the state of the system's environmental variables, being available at runtime to our application.

Why Mock process.env?

Most of the time when developing an application we don't really need the process.env variable or it's properties values, but in some parts of the application we do need them, for example if we need to grab the app's version in runtime or the app's port to start a server of some kind.

To make sure that the app behaves the way we want it to, we need to test it thoroughly and this mean we need to test the parts of the app that rely on this object and this is the case where we need to mock process.env to test different cases the app can run into.

Mock process.env in Jest Tests

For the sake of this post, we will have a very simple NodeJs app that has one file with two functions; appEnv and appVersion which will print out the app's env and version respectively.

Create a file named app.js and copy the following content into it:

function appEnv() {
  const currentEnv = process.env.NODE_ENV

  if (!currentEnv) {
    throw new Error('NODE_ENV is not defined')
  }

  return `App is running on ${currentEnv} environment`
}

function appVersion() {
  const currentAppVersion = process.env.APP_VERSION

  if (!currentAppVersion) {
    throw new Error('APP_VERSION is not defined')
  }

  return `App's version is ${currentAppVersion}`
}

module.exports = { appEnv, appVersion }

As you can see, we only print out the values here, and if the value is undefined we throw an error, pretty simple.

Now that we got this out of the way, we can start.
Mocking process.env is actually pretty simple, but first we need to know where we can set those values for our tests after that we will mock them in our tests.

App Wide Mocking

The default values for every test can be set in one of Jest's setup files, when this is done, the setup file will be executed before each test file.

To setup Jest setup-files execute the following steps:

First, create a jest.config.js file in the root of the directory (besides package.json).
Content of the config file would be:

module.exports = {
  setupFiles: ['<rootDir>/jest-setup.js'],
}

Then, create a setup-jest.js file in the root of the directory too.
Content of the file should be our default values:

process.env.NODE_ENV = 'local'
process.env.APP_VERSION = 'v0.1'

Now we did setup the default values for the whole app's tests env, Let's mock them!

First, create a test file named app.test.js next to app.js file.
Then we can start our tests in a dedicated test suite (App Tests - Default ENV Values) as you can see below:

const { appEnv, appVersion } = require('./app')

describe('App Tests - Default ENV Values', () => {
  const originalEnv = process.env

  afterEach(() => {
    // Reset process.env after each test case
    process.env = originalEnv
  })

  describe('APP_VERSION Tests', () => {
    it('should return default value when APP_VERSION', () => {
      const result = appVersion()

      expect(result).toBe(`App's version is v0.1`)
    })

    it('should throw an error if APP_VERSION is not defined', () => {
      process.env = { APP_VERSION: undefined }
      // OR process.env = {}

      expect(appVersion).toThrow('APP_VERSION is not defined')
    })
  })

  describe('NODE_ENV Tests', () => {
    it('should return default value when NODE_ENV', () => {
      const result = appEnv()

      expect(result).toBe('App is running on local environment')
    })

    it('should throw an error if NODE_ENV is not defined', () => {
      process.env = { NODE_ENV: undefined }
      // OR process.env = {}

      expect(appEnv).toThrow('NODE_ENV is not defined')
    })
  })
})

Now let's talk about the above tests, first we created a test group named App Tests - Default ENV Values which contains two other groups APP_VERSION Tests and NODE_ENV Tests.

Before we dive into the tests, notice we have a variable to hold the original env object's value, that's important because in some tests we do override the process.env properties and we need to reset it to the original value after each test case.

Our first test case, in both groups, ensures that our env variables are correct and picked up from the setup file we had earlier.

Second test case again in both groups is different, we override the process.env value to set undefined values for our properties (NODE_ENV & APP_VERSION) and those tests should ensure that our code will throw an error when those values are missing from env variable.

Per Test File Mocking

Now since we mocked the app-wide env variable, let's find out how to mock the env variables in a test file/suite in case we don't have a setup file or we just want to test different values other than the values in the setup file.

In the same app.test.js file, we can add another group named App Tests - Manual ENV Values right next to App Tests - Default ENV Values (just to keep the test file clean and clear).

describe('App Tests - Manual ENV Values', () => {
  const originalEnv = process.env

  beforeEach(() => {
    // Override process.env object before each test case:
    process.env = {
      NODE_ENV: 'prod',
      APP_VERSION: 'v1.0',
    }
    // By default the value of process.env.NODE_ENV is test when running tests with jest
  })

  afterEach(() => {
    // Reset process.env value after each test case
    process.env = originalEnv
  })

  describe('APP_VERSION Tests', () => {
    it('should return correct value when APP_VERSION is defined', () => {
      const result = appVersion()

      expect(result).toBe(`App's version is v1.0`)
    })

    it('should throw an error if APP_VERSION is not defined', () => {
      process.env = { APP_VERSION: undefined }
      // OR process.env = {}

      expect(appVersion).toThrow('APP_VERSION is not defined')
    })
  })

  describe('NODE_ENV Tests', () => {
    it('should return correct value when NODE_ENV is defined', () => {
      const result = appEnv()

      expect(result).toBe('App is running on prod environment')
    })

    it('should throw an error if NODE_ENV is not defined', () => {
      process.env = { NODE_ENV: undefined }
      // OR process.env = {}

      expect(appEnv).toThrow('NODE_ENV is not defined')
    })
  })
})

Again, let's talk about our new test group.

Actually, not much changed, In the new test group we mock or set custom values for the process.env object before each test case which allows us to have more control over the values in our test file instead of the globally set variables.

Conclusion

At last, in this post we saw how we can set our env variables globally while testing our application along with a per-test mock of the env object.

Source code can be found here.

As always, I hope you learned something.

Found this useful? feel free to share it with your friends.

Join the newsletter from here to notify you of new posts and updates.

Like the post? consider buying us a coffee ❤️.

We all use JSON.stringify() method for various reasons, but very few know about it's hidden optional parameters, and in this BitCode we will discover them with examples.

Table of contents

• Normal Usage
• Whitelist Object's Properties
• Replacer Function
• Output Spacing

Normal Usage

Before we start, this is just a quick example of a normal usage, we can use it as reference/comparison to what's coming up next.

const user = {
  name: 'John',
  age: 20,
  isSingle: true,
}

const result = JSON.stringify(user)

console.log(result)
// Output: {"name":"John","age":20,"isSingle":true}

Whitelist Object's Properties

We can choose what properties we want to include in the stringified output by passing a list of string values that represents the whitelisted properties.

const user = {
  name: 'John',
  age: 20,
  isSingle: true,
}

const result = JSON.stringify(user, ['name'])

console.log(result)
// Output: {"name":"John"}

Replacer Function

We can also have a function to format our data before it's printed, the replacer function has two parameters, a key and a value (self-explanatory).
To demonstrate the power of the replacer function, we will add a password field to our user object, and to keep our users safe, we will replace the password value with a static one as follows:

const user = {
  name: 'John',
  age: 20,
  isSingle: true,
  password: 'super_sensitive_password' // Our new field
}

// Replacer function's name doesn't matter.
const replacer = (key, value) => {
    if (key === 'password') {
        return '****'
    }

	return value
}

const result = JSON.stringify(user, replacer)

console.log(result)
// Output: {"name":"John","age":20,"isSingle":true,"password":"****"}

Output Spacing

Finally, we can make our output more readable by passing a third argument to represent the amount of whitespace to be inserted (could be a string indentation/line break or a number for normal spacing).
Also, we don't have to pass a replacer function to insert some spacing, and this is exactly what we will do (we can pass either an undefined or a null to the second argument).

const user = {
  name: 'John',
  age: 20,
  isSingle: true,
}

const space = JSON.stringify(user, null, 2)

console.log(space)
/**
 * Output:
 * {
 *   "name": "John",
 *   "age": 20,
 *   "isSingle": true
 * }
 */

const indentation = JSON.stringify(user, null, '\t')

console.log(indentation)
/**
 * Output:
 * {
 *  	"name": "John",
 *  	"age": 20,
 *  	"isSingle": true
 * }
 */

Conclusion

At last, we discovered the lesser known parameters of the JSON.stringify() method.

As always, I hope you learned something.

Found this useful? feel free to share it with your friends.

Join the newsletter from here to notify you of new posts and updates.

Like the post? consider buying us a coffee ❤️.

Learn how to use Git stash in case you ever wondered how to save your changes without committing them; that's exactly the point from Git stash, you stash the changes in a dirty working directory.

In this BitCode you will learn the essentials of Git stash to get going.

When To Use Git Stash?

Often when you work on some part of a project, and you would like to switch to work on another thing unrelated in even a different branch, you would like to save your changes without committing them; maybe because they are undone or needs some refactoring.

This is where Git stash is super useful, now let's dive into the essential commands.

Create a Git Stash

To create a stash, there are two commands to do it.

Both git stash/git stash push; will create an entry holding the current

Note: Keep in mind that Git stash will only hold changes from already tracked files and/or staged changes; meaning if you just created a file, you will have to stage it first before being able to stash it.

Creating a stash is awesome, but it stores the stashes with a naming like WIP on branchname which is not ideal if you have a lot of stashes.

So to create a stash with a message, you can use the following command:

git stash push -m "A message so I can remember what this stash is about"

Like this, you won't forget what the stash is about, and you will be able to apply a stash to the working directory with ease from the list.

List & Retrieve Git Stashes

Now we will see how to list Git stashes and apply them into our working directory.

To list the stashes:

git stash list

# Should print something like this:
# stash@{0}: On master: Another stash for a new feature
# stash@{1}: On master: A stash with a message

To retrieve a stash:

Before we start retrieving the stashes, we need to know the commands used and the difference between them.

The commands are: git stash apply and git stash pop

The difference between them is that apply applies the stash to the working directory and keeps the stash entry intact, while pop applies the stash and removes the stash entry from the list.

Now that this is cleared out, let's dig into it:

# Apply the most recent stash:
git stash apply # or git stash pop

# Apply a specific stash by it's index
git stash apply <index> # or git stash pop <index>

Keep in mind that while applying a stash you can encounter a conflict, this is normal you just have to solve it as any other merge conflict.

In the case of using pop the stash is not removed, so after solving the conflict you should remove the stash manually by using drop which is next in the post.

Drop a Stash or Clear All Stashes

As you can create, you can delete, and you have the choice to delete a specific stash or clear out the list.

To delete a single stash:

git stash drop <index>

To clear out the whole list:

git stash clear

Conclusion

Git has a lot under it sleeves, and Git stash is one of those things I wish I learned since day one.

Sources

• Git docs
• Git book docs

Setting up Redux with persistence in local storage in a web React application is fairly easy, but in React Native, It's a slightly different process and tools.

In this post, we will see how to set up Redux with storage persistence in React Native.

Table of Contents

• Requirements
• Start a React Native Project
• Create a Counter Component
• Install Redux and Create a Store
• Create Counter Slice
• Use Redux in Counter Component
• Add Store Persistence
• Conclusion
• Sources

Requirements

• Basic React and React Native knowledge
• Basic Redux knowledge
• Basic Typescript knowledge

Start a React Native project

Obviously we need a project to work on, if you don't have a project for this, start from here.

Create a project with Typescript template:

npx react-native init react_native_redux --template react-native-template-typescript

This command creates a project with the following file structure:

Now let's move on to create some visuals.

Create a Counter component

To demonstrates and test the Redux installation we will need to create a component for that, I chose a counter for its simplicity:

Visually, it should look like this:

Of course, you can run the app now with:

npm run android

Install Redux and create a Store

Now we can install Redux, in this step we will be installing Redux Toolkit and React-Redux bindings packages:

npm i react-redux @reduxjs/toolkit

Now for the store, create a file in the root of the project named store.ts and paste the following code in it:

import {configureStore} from '@reduxjs/toolkit';

export const store = configureStore({
  reducer: {},
});

export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

This is an empty Store, we will populate it later on.

One last step is to wrap our main component with the store provider:

Create Counter Slice

Now it's time to integrate our Counter logic with Redux using the Slice file:

Create a file in the root project named counterSlice.ts with the following code:

This file will export actions, selector and the reducer.

We also need to update the store with our reducer, like so:

That's enough for now, let's move on to our Counter component.

Use Redux in Counter component

After we created our Slice file for the counter, we can update our component to use those actions.

We will use the selector to get the counter value and dispatch the exported actions to update it.

Have the component updated like so:

After adding the changes shown above, you can run the app and test it, it should run as if we are still using the useState hook.

But there is something we didn't add to our project, which is persistence, we will cover this in the next step.

Add Store  Persistence

Now it's time to persist our store, but in React Native we are talking about a mobile device, so there is no local storage, in this case, we will be using two packages; Redux Persist to persist and rehydrate our store and Async Storage as storage adapter.

Let's start by installing the packages:

npm i redux-persist @react-native-async-storage/async-storage

Now let's add persistence to our application:

In the Store file, we will have some changes:

And we also need to wrap our main component with the PersistGate like so:

And now we should have our store persisted, you can test this by missing around with the counter, close the app, re-open it, and you should see the latest value persisted.

Conclusion

No doubt, it takes some effort to setup Redux in React Native, but it's totally worth it.

Sources

• React Native development environment setup.
• Redux Toolkit documentation.
• Redux Persist
• Async Storage

Source code can be found here.

As always, I hope you learned something.

Found this useful? feel free to share it with your friends.

Join the newsletter from here to notify you of new posts and updates.

Like the post? consider buying us a coffee ❤️.

Dark mode is everywhere nowadays, and probably one of the best things in a website (at least for us, the developers), Together in this post we will learn how to implement dark mode in a React application using TailwindCSS for styles and React's Context API for data passing and theme switching.

Table of Contents

• Requirements
• Why Use TailwindCSS?
• Why Use Context API?
• Create the Project
• Install Dependencies and Setup
• Create Components
• Create Theme Context and Wrapper
• Tweak ThemeSwitch Component
• Conclusion
• Sources

Requirements

• Basic understanding of React and Typescript

Why Use TailwindCSS?

The main reason I'm using TailwindCSS is it's ease of use, especially when it comes to dark mode.

We will be using the class strategy instead of the media strategy to manually trigger dark mode.

Why Use Context API?

We will be using the Context API for two reasons, the first is to pass data down to whatever child component we want (the one responsible for theme switching) and the second is to update the theme.

Create the Project

Before the darkness, we need a project, the project used in this post is generated with Create React App using the Typescript template.

Run the following command to generate a project:

npx create-react-app react-dark-mode-context --template typescript

Feel free to change the name of the project.

Install Dependencies and Setup

For the project dependencies, we don't have much – it's just TailwindCSS because Context API is a built-in API/Hook in React.

Install TailwindCSS:

npm i -D tailwindcss postcss autoprefixer

And initialize project's configuration:

npx tailwindcss init

Now you will have two files generated, we need to tweak the Tailwind config file to include our src and to specify the dark mode strategy:

The config file should look something like this:

module.exports = {
  content: ['./src/**/*.{js,jsx,ts,tsx}'],
  theme: {
    extend: {},
  },
  plugins: [],
  darkMode: 'class',
}

Now add the Tailwind directives to our root styles file (It's the index.css file) :

@tailwind base;
@tailwind components;
@tailwind utilities;

That's it for the installation and setup, let's move on.

Create Components

For the sake of this post, let's keep things as simple as we can.

For that reason, below you will see we have two components (not including the App component).

So, let's create these components (order doesn't matter, but it will be easier if you follow the below order):

Create a components folder in the src folder, then create a file for each component (except the App.tsx file, it's already there).

The ThemeSwitch component:

import React from 'react'

const ThemeSwitch = () => {
  return (
    <button
      style={{
        padding: 5,
        borderRadius: 5,
        color: 'black',
        background: 'white',
      }}
    >
      Go DARK MODE
    </button>
  )
}

export default ThemeSwitch

The MainComponent component:

import { FC } from 'react'
import logo from '../logo.svg'
import ThemeSwitch from './ThemeSwitch'

const MainComponent: FC = () => {
  return (
    <div className='font-sans flex flex-col justify-center items-center h-screen dark:bg-zinc-700 dark:text-white'>
      <img src={logo} width={200} alt='React Logo' />
      <h1 className='text-2xl'>Hello World!</h1>
      <h2>React + TailwindCSS Dark Mode App</h2>
      <div className='mt-2'>
        <ThemeSwitch />
      </div>
    </div>
  )
}

export default MainComponent

Note that I added some dark mode styles in the component using the dark: keyword, we will see the effect once we implement the theme context and switching.

The App component:

import { FC } from 'react'
import MainComponent from './components/MainComponent'

const App: FC = () => {
  return <MainComponent />
}

export default App

All good, let's implement the theme switching using the Context API.

Create Theme Context and Wrapper

Now we are in the exciting part, the Context API – in this section we will create two files, one for the theme context and the other for the wrapper, you might ask why we need a wrapper? It's just to make the App component as clear and clean as possible.

Create a context folder in the src folder.

The ThemeContext file:

import { createContext } from 'react'

const defaultValue = {
  currentTheme: 'light',
  changeCurrentTheme: (newTheme: 'light' | 'dark') => {},
}

const ThemeContext = createContext(defaultValue)

export default ThemeContext

This file has the context, and it's default value, currentTheme is self-explanatory and the method changeCurrentTheme is the method responsible for theme switching (we will write its implementation/content in the wrapper).

The ThemeContextWrapper component:

import { useState, useEffect, FC, ReactNode } from 'react'
import ThemeContext from './ThemeContext'

const ThemeContextWrapper: FC<{ children: ReactNode }> = ({ children }) => {
  const [theme, setTheme] = useState(localStorage.getItem('theme') || 'light')

  const changeCurrentTheme = (newTheme: 'light' | 'dark') => {
    setTheme(newTheme)
    localStorage.setItem('theme', newTheme)
  }

  useEffect(() => {
    if (theme === 'light') document.body.classList.remove('dark')
    else document.body.classList.add('dark')
  }, [theme])

  return <ThemeContext.Provider value={{ currentTheme: theme, changeCurrentTheme }}>{children}</ThemeContext.Provider>
}

export default ThemeContextWrapper

This is the real deal here, the core of operations – let me explain what happens here.

We need to make it clear that Context's values are being accessible for child components if they are wrapper around a provider (what we return in this case), this explains why we have children as props to this component, inside the component we have a simple state for the current theme also the implementation of the previous method we discussed that changes the theme.

At first render, the component checks for the current value stored in local storage (yes, this project is preference-capable, surprise!) if the value is not found then we fall-back to light mode, all this happens in the useState hook at first.

Then based on that state the useEffect is triggered to set the suitable class (which is basically adding pr removing the dark class from the document body, remeber we said we are using the Tailwind class strategy? Well, this is it).

The useEffect will run every time the theme value from the state changes, which happens when the changeCurrentTheme function is called, we update the state's value with the new theme selected and persist this value in local storage.

That's it, it's this simple.

Tweak ThemeSwitch Component

There is one thing we need to change in the ThemeSwitch component, we need to use the ThemeContext values and capabilities.

Open up that component and edit like below:

import React from 'react'
import ThemeContext from '../context/ThemeContext'

const ThemeSwitch = () => {
  const { currentTheme, changeCurrentTheme } = React.useContext(ThemeContext)

  return (
    <button
      data-testid='switch-theme-btn'
      style={{
        padding: 5,
        borderRadius: 5,
        color: currentTheme === 'light' ? 'white' : 'black',
        background: currentTheme === 'light' ? 'black' : 'white',
      }}
      onClick={() => changeCurrentTheme(currentTheme === 'light' ? 'dark' : 'light')}
    >
      Go {currentTheme === 'light' ? 'DARK MODE' : 'LIGHT MODE'}
    </button>
  )
}

export default ThemeSwitch

You can notice that we are accessing the current theme value and the method to switch themes using the Context hook.

The current theme value is used to determine the styles in the component, as well as the value passed to the method when being called after clicking the switching button.

Now, that's it for real, we have a dark mode enabled React application.

Conclusion

As we saw, in simple steps we implemented dark mode in a React app, now it's up to you to change the styles using Tailwind dark: keyword to make the necessary changes for a dark environment.

Live demo

Sources

• Create React App
• React Context
• TailwindCSS installation and dark mode

Source code can be found here.

As always, I hope you learned something.

Found this useful? feel free to share it with your friends.

Join the newsletter from here to notify you of new posts and updates.

Like the post? consider buying us a coffee ❤️.

Hey folks, Sense I started this blog I occasionally get asked about the process to create a blog post, so in this BitCode I will share my process to create and publish an IT blog post.

Flowchart

Below is a Flowchart for the post creation process:

Download PDF

JavaScript's functions with the Rest parameters (also commonly called Rest Operator) are simply JavaScript's ways to implement variadic functions, and in this BitCode we will take a quick look into it along with some examples.

It allows a function to accept an unlimited number of arguments that will be available as a list inside the function.

The Syntax

The Rest parameters syntax is a sequence of three dots ... followed by an argument name, all inside the parentheses of a function.

Please do not confuse Rest Parameters with the Spread Syntax, take a look at this BitCode or click the link below to know more about it.

Javascript’s Spread Syntax

What is the Spread Syntax and its common uses in Javascript ES6.

RAZINJ DevNizar Jailane

Quick Notes

Some notes to write down before start using the Rest parameter.

• A function can only have one Rest parameter,
• The Rest parameter should be the last parameter in the function definition.

After clearing these points, let's take a look at some examples.

Examples

Let's see a couple of examples using the Rest parameter.

• Find the max of undefined number of items

const findMax = (...numbers) => {
    return Math.max(...numbers)
}

console.log(findMax(1, 2, 4, 100, 410, 0))
// Output: 410

• Get the sum of a bunch of number

const sum = (...numbers) => {
    return numbers.reduce((x, y) => x + y, 0)
}

console.log(sum(10, 2, 3, 89))
// Output: 104

JavaScript introduced a bunch of new features in ES6, one of them is the Spread Syntax (also commonly called Spread Operator), and in this BitCode we will have a look at it, and its common uses.

The Syntax

The spread syntax is a sequence of three dots ..., pretty simple, the syntax allows an iterable to be expanded in other places.

The same syntax has another use in JavaScript's functions, you can learn more in this BitCode, or by clicking the link below.

Javascript’s Rest Parameters

What are the Rest Parameters in Javascript along with some usage examples.

RAZINJ DevNizar Jailane

Common Uses

There are a lot of common uses for it, let's take a look into them one by one.

Concatenate Arrays and Objects

The spread syntax allows us to concatenate multiple lists or objects in a simple syntax, Let's see the code.

Using arrays:

const arr_1 = [1, 2, 3]
const arr_2 = [4, 5, 6]

const all_arrays = [ ...arr_1, ...arr_2 ]

console.log(all_arrays)
// Output: [ 1, 2, 3, 4, 5, 6 ]

Using objects:

const obj_1 = { foo: 'foo_value' }
const obj_2 = { bar: 'bar_value' }

const object_with_all_keys = { ...obj_1, ...obj_2 }

console.log(object_with_all_keys)
// Output: { foo: 'foo_value', bar: 'bar_value' }

Deep Copy (Reference Change)

The spread syntax can also be used to make a deep copy for arrays and objects that changes the memory reference (the same result can be achieved with ES5's Object.assign).

To better see the change the spread syntax provides in this regard, let's see a typical copy and its behavior:

const obj_1 = { foo: 'foo_value' }
const obj_2 = obj_1

obj_1.foo = 'foo_value_updated'

console.log(obj_1, obj_2)
// Output: { foo: 'foo_value_updated' } { foo: 'foo_value_updated' }

As we can see, after we updated the value of foo in obj_1 the same change is reflected in obj_2 and this is unwanted behavior.

Now let's fix this by using the spread syntax:

const obj_1 = { foo: 'foo_value' }
const obj_2 = { ... obj_1 }

obj_1.foo = 'foo_value_updated'

console.log(obj_1, obj_2)
// Output: { foo: 'foo_value_updated' } { foo: 'foo_value' }

Magic, three dots solved an issue.

PS: Deep copy (clone) is not going to work with nested data structure (nested array or object).

Spread Strings

Another use is spreading a string into a list of characters.

const a_string = 'Hello World!';

const list_of_chars = [ ...a_string ]

console.log(list_of_chars)
// Output: ['H', 'e', 'l', 'l', 'o', ' ', 'W', 'o', 'r', 'l', 'd', '!']

Docker Registry is a registry for Docker images that is used by Docker Hub, but the problem with Docker Hub is that we get only one private repository for our image and in case we need multiple private images self hosting is a Docker registry in our existing server is the best option, and in this post, we will be doing just that.

Table of contents

• Requirements
• Notes in self-hosting a registry
• Install with Docker Compose
• Use NGINX as a proxy
• Conclusion
• Sources

Requirements

• Docker
• Docker Compose
• Basic understanding of Docker and Docker Compose
• NGINX

Notes in self-hosting a registry

There are two notes about self-hosting your own Docker Registry in production that I would like you to know.

• Using Docker Registry in a production environment requires a secure connection (SSL/TLS).
• It's best to proxy the registry through NGINX web server for more control and security.

After taking notes, we can start installing the registry.

Install with Docker Compose

We will be installing the registry using Docker Compose, for ease of use.

Create a docker-compose.yml file:

touch docker-compose.yml

Paste the following content into the file:

version: '3'

services:
  app:
    image: registry:2
    container_name: docker-registry
    restart: unless-stopped
    environment:
      REGISTRY_AUTH: htpasswd
      REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
      REGISTRY_AUTH_HTPASSWD_REALM: Local Registry Realm
    ports:
      - 127.0.0.1:8000:5000
    volumes:
      - ./data:/var/lib/registry
      - ./auth:/auth:ro

In this file we describe our registry, using the local port 8000 and local volumes for our data and authentication (we will get into this below).

Since we specified our auth method to htpasswd (basic auth) we need to generate htpasswd file using this command:

docker run --entrypoint htpasswd httpd:2 -Bbn my_registry_user my_registry_password > htpasswd

This will create a file named htpasswd with content similar to this:

# cat htpasswd
my_registry_user:$2y$05$mexS70Ju7VkXag5X7EzDI.Mrt5JZPU5K3mh1oPL0oydhTj2HMpUk.

Now to make this work with our docker-compose.yml file we need to create the auth directory and move the file into it like this:

mkdir auth && mv htpasswd auth

Our file tree should look like this:

We are now done with the installation preparation, let's run the registry now:

docker-compose up -d

Check the logs to see if there are any errors:

docker-compose logs -f

If it's all good, move on to the next step.

Use NGINX as a proxy

In order to expose the registry to the internet, we will be using NGINX as a proxy web server.

For a specific domain or subdomain, we can use the following configuration:

upstream docker_registry_app {
    server 127.0.0.1:8000;
}

server {
    listen 443 ssl http2;
    server_name sub.domain.com;

    # ssl
    ssl_certificate /etc/nginx/certificates/domain.com.pem;
    ssl_certificate_key /etc/nginx/certificates/domain.com.key;

    # logging
    access_log /var/log/nginx/sub.domain.com.access.log;
    error_log /var/log/nginx/sub.domain.com.error.log warn;

    client_max_body_size 0;

    # reverse proxy
    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_read_timeout 900;

        proxy_pass http://docker_registry_app;
    }
}

# https www redirect
server {
    listen 443 ssl;
    server_name www.sub.domain.com;

    # ssl
    ssl_certificate /etc/nginx/certificates/domain.com.pem;
    ssl_certificate_key /etc/nginx/certificates/domain.com.key;

    return 301 https://sub.domain.com$request_uri;
}

# http and www redirect
server {
    listen 80;
    server_name sub.domain.com www.sub.domain.com;

    return 301 https://sub.domain.com$request_uri;
}

Please note that client_max_body_size 0; means there is no limit to the body size, feel free to adapt the value to your needs.

After adding or changing the NGINX config, restart with:

sudo nginx -t && sudo nginx -s reload

Now, you can test if everything is working fine by visiting the following URL in your browser:

https://sub.domain.com/v2/_catalog

You will be asked to enter your basic auth credentials (the username and password you used to generate the htpassed file earlier).

Conclusion

Like this, I can say we are successfully self-hosting our own private Docker Registry ready for production use.

Sources

• Docker Registry website.
• Docker Registry HTTP API specs.

As always, I hope you learned something.

Found this useful? feel free to share it with your friends.

Join the newsletter from here to notify you of new posts and updates.

Like the post? consider buying us a coffee ❤️.

Strapi 4 is released and it's awesome, but the Docker image is not yet released, and it's not known when they will release it for us, but this won't stop us from running Strapi in Docker and that's what we will be covering in this post.

Table of contents

• Requirements
• Create the Strapi Project
• Add Docker Support
• Docker Support Caveat
• Run and Verify Project
• Content Types Development
• Conclusion

Requirements

• NodeJs
• Docker
• Docker Compose

Create the Strapi Project

We need to create a Strapi project named app (I will explain why this name at a later point) using npx:

npx create-strapi-app@latest app

The command will generate a project with the following file architecture:

Add Docker Support

Now we will add Docker support using a Dockerfile.

In this step, the Dockerfile file needs to be created in the root of the Strapi project, after creating the file copy the following content into it:

FROM strapi/base

# Let WatchTower know to ignore this container for checking
LABEL com.centurylinklabs.watchtower.enable="false"

WORKDIR /app

COPY ./package*.json ./

RUN npm ci

COPY . .

ENV NODE_ENV production

RUN npm run build

EXPOSE 1337

CMD ["npm", "start"]

The Dockerfile will install Strapi's dependencies and build the project in production mode while exposing the port 1337.

To further optimize the Docker image that will be produced by this Dockerfile we skip copying some files and directories that won't be used inside the container.

Ignoring files and directories can be achieved by using a special file called .dockerignore (similar in nature to .gitignore).

Create the Docker ignore file in the root directory of the project, and copy the following content to it:

node_modules
license.txt
exports
*.cache
build
.strapi-updater.json

So far so good, we added Docker support to our project, but we are not done yet.

Docker Support Caveat

There is a caveat when building Strapi in a Docker container, Strapi uses webpack to build the admin view (which happens when running npm run build).

To make this Dockerfile effective, we need to supply this build dependency via our package.json file, to do this install webpack as a development dependency:

npm i -D webpack

With that done, now, we need to create a docker-compose.yml file, which needs to be outside of the root directory of the Strapi project.

So we need to wrap the project and the docker-compose.yml in a directory (that's why I called the project app above), let's do this:

# Step out of the Strapi project named 'app'
cd ..

# Create a new directory
mkdir strapi-v4

# Move the Strapi project into the newly created directory
mv app strapi-v4

Now after wrapping the project in a directory, step into the directory and create the docker-compose.yml file:

# Step into the wrapper directory
cd strapi-v4

# Create an empty file
touch docker-compose.yml

Now, paste the following content into the file:

version: "3"

services:
  app:
    build:
      context: ./app
    container_name: strapi_v4_app
    restart: unless-stopped
    environment:
      NODE_ENV: production
      DATABASE_CLIENT: postgres
      DATABASE_HOST: db
      DATABASE_PORT: 5432
      DATABASE_NAME: app
      DATABASE_USERNAME: db_username
      DATABASE_PASSWORD: db_password
    volumes:
      - ./app:/srv/app
    ports:
      - 127.0.0.1:8000:1337
    depends_on:
      - db

  db:
    image: postgres:13
    container_name: strapi_v4_db
    restart: unless-stopped
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: db_username
      POSTGRES_PASSWORD: db_password
    volumes:
      - ./data:/var/lib/postgresql/data

Let me explain the file for you, the Docker Compose file contains two services; the Strapi project we just created named app (it can be named anything) and a database service that the project will connect to.

Run and Verify Project

Now, we can create our Docker containers and enjoy our CMS, let's do it:

Build and run:

docker-compose up -d --build

Verify that both services are running:

docker ps -a

The expected output would be something similar to this:

After it finishes you can go to your browser and get into: http://localhost:8000/admin to create an admin profile, and basically, this is it.

But since this build is a production build, you can't create types, you will need to create them in the development environment, and that is what's next.

Content Types Development

In this section, we will see how to create our content types and update the previously built production environment.

Let's start with how it works, first whatever content type you create from the UI translates into code inside of the Strapi project and that's something that can't be done in the production environment.

Now that's cleared out, let's launch the development environment and create a content type then update the production build.

First, we need to launch our local database for development, but before that let's create an extension file for the database to expose the database port:

Right next to the original docker-compose.yml create a new file:

touch docker-compose.dev.yml

And paste the following content into it:

version: "3"

services:
  db:
    ports:
      - 5432:5432

Now launch the database only specifying both files:

# In the strapi-v4 directory
docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d db

Verify that's the database is created and that it exposes the port we specified:

docker ps -a

Second, we need to launch the Strapi project from within the project's root directory using npm:

# Get into the Strapi project directory
cd app

# Start development server
npm run develop

Like this, the project will connect to the database using the credentials supplied in the database.js file.

Now using your browser head into the admin panel at http://localhost:1337/admin and start creating your content types.

As soon as you create a content type, you will notice that the code in the project's directory changed (some files are created).

We are almost done, we need to update the production environment (which is not the one in your local machine), to do this just launch our previous command:

docker-compose up -d --build

This will re-build the project using the production environment and you can start using the CMS.

Conclusion

Like this, we can say that we built our custom Strapi 4 docker image and containers with ease.

Source code can be found here.

As always, I hope you learned something.

Found this useful? feel free to share it with your friends.

Join the newsletter from here to notify you of new posts and updates.

Like the post? consider buying us a coffee ❤️.

As a developer or sysadmin running a number of Docker containers, it is critical that you keep them updated regularly when a new release or a security patch is out for your images.

Being informed is not easy, If you go by checking the Docker image homepage or its releases page, that's not practical and a waste of time.

In this post, we will see two ways to get notified about newly released Docker images.

Table of contents

• Requirements
• The Idea
• WatchTower
• WatchTower Start and Verification
• Bonus Tool, Diun
• Conclusion
• Sources

Requirements

• Docker
• Docker Compose
• Basic understanding of Docker and Docker Compose

The Idea

You would want something to check the image latest version with the version you are currently running, automatically!, If a newer version is found, you should be notified, then you can examine the change-log and act upon that (you do check the change-log right?)

For this we have a tool for the job and a bonus one at the bottom, Let's discover them.

WatchTower

WatchTower is not only notifying you about new releases but also updates the running containers for you, however, this is not the ideal output we want since sometimes the new release can be a breaking one or needs some kind of preparation ahead of deploying it.

Let's see how we can make it work.

WatchTower works also as a Docker container, for that we will be writing a Docker Compose file to set our configuration for it.

Create a docker-compose.yml file and paste the following into it:

version: "2"

services:
  app:
    image: containrrr/watchtower
    hostname: SERVER_NAME
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - TZ=Africa/Casablanca
      - NO_COLOR=true
      - WATCHTOWER_SCHEDULE=0 0 19 * * *
      - WATCHTOWER_INCLUDE_STOPPED=true
      - WATCHTOWER_INCLUDE_RESTARTING=true
      - WATCHTOWER_MONITOR_ONLY=true
      - WATCHTOWER_NOTIFICATIONS=gotify
      - WATCHTOWER_NOTIFICATION_GOTIFY_URL=http://192.168.1.197:8001/
      - WATCHTOWER_NOTIFICATION_GOTIFY_TOKEN=A0e2ekUPRRiNhu_
      - WATCHTOWER_NOTIFICATION_GOTIFY_TLS_SKIP_VERIFY=true

Before spinning the container up, we will go throw the environment variables used there:

• WATCHTOWER_SCHEDULE is where you define when WatchTower will look for updates.
• WATCHTOWER_INCLUDE_RESTARTING and WATCHTOWER_INCLUDE_STOPPED are to tell WatchTower to look for updates for stopped and restarting containers as well.
• WATCHTOWER_MONITOR_ONLY used to tell WatchTower to not update (this is where notifications only part is).
• WATCHTOWER_NOTIFICATIONS this is where you define the notifications channels where possible values are email, slack, msteams, shoutrrr, and gotify (gotify is what we are using in this example, feel free to use whatever notification channel you want or need, we have a post on how to install it).
• WATCHTOWER_NOTIFICATION_GOTIFY_URL, WATCHTOWER_NOTIFICATION_GOTIFY_TOKEN and WATCHTOWER_NOTIFICATION_GOTIFY_TLS_SKIP_VERIFY are used to define the Gotify server information.

The other options are up to you to adapt like TZ (TimeZone), NO_COLOR, and docker-compose argument hostname so you can identify from where the notifications are coming.

WatchTower Start and Verification

Start the container up with:

docker-compose up -d

Check the logs for any errors thrown with:

docker-compose logs

You should see something similar to the following):

Attaching to watchtower_app_1
app_1  | time="2021-11-22T21:37:54+01:00" level=warning msg="Using an HTTP url for Gotify is insecure"
app_1  | time="2021-11-22T21:37:56+01:00" level=info msg="Watchtower 1.3.0\nUsing notifications: gotify\nChecking all containers (except explicitly disabled with label)\nScheduling first run: 2021-11-23 19:00:00 +0100 +01\nNote that the first check will be performed in 21 hours, 22 minutes, 3 seconds"

After checking the logs, in Gotify you should see a notification already carrying almost the same information:

If the above checks, we can say the setup was successful, now every day at 19:00 you will receive a notification if there is a container that needs to be updated so you can take action.

Here is a sample notification (where M0, M1 and CM1 are names of servers I maintain):

Bonus Tool, Diun

Diun (Docker Image Update Notifier), is a similar service, actually, it was built for the purpose of notifications only (unlike WatchTower, which can do both; notify and/or update).

We will see below how you can deploy and use it, then you can be the judge and use what you feel comfortable with.

To install it, you will do the same thing as WatchTower, create a docker-compose.yml file and paste the following into it:

version: "3.5"

services:
  diun:
    image: crazymax/diun:latest
    container_name: diun
    restart: unless-stopped
    command: serve
    volumes:
      - ./data:/data
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - TZ=Africa/Casablanca
      - LOG_LEVEL=info
      - LOG_JSON=false
      - DIUN_WATCH_WORKERS=20
      - DIUN_WATCH_SCHEDULE=0 19 * * *
      - DIUN_PROVIDERS_DOCKER=true
      - DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=true
      - DIUN_PROVIDERS_DOCKER_WATCHSTOPPED=true
      - DIUN_NOTIF_GOTIFY_ENDPOINT=http://192.168.1.197:8001/
      - DIUN_NOTIF_GOTIFY_TOKEN=AVcPmg-d9sE-Z8s

Feel free to make the required changes to make it work, like changing the gotify notification information and credentials along with the schedule and timezone.

Launch it with:

docker-compose up -d

Below is a sample of Diun's notifications:

Conclusion

Personally, I like how WatchTower delivers notifications with a list of all updates available for each server I have while Diun is sending a notification for each update available.

But it's up to you to decide and choose between the two!

Sources

• WatchTower source code and website
• Diun source code and website

As always, I hope you learned something.

Found this useful? feel free to share it with your friends.

Join the newsletter from here to notify you of new posts and updates.

Like the post? consider buying us a coffee ❤️.

Most of the developers are using Git as their version control system and sometimes it comes in handy to have Git set up and configured for multiple accounts for example work and personal configs and accounts.

In this post, we will see why and how to set up multiple configurations for a seamless workflow.

Tables of contents:

• Requirements
• Why?
• How?
• Conclusion

Requirements

• Git installed and basic understanding

Why?

The main use case for this kind of setup is when you have a single machine on which you develop and code on work and personal projects where you usually don't have the same Git accounts for both of them.

How?

You can start by installing Git if you haven't already, after that we will be creating two files for each account/config, by default none of these files are created.

Let's start by checking them (run command in your home directory ~):

cd ~ && ls -la | grep .gitconfig

The above command should output no files.

I will be assuming that you have the following file structure for work and personal projects, but you can adapt as needed.

/home/nizar/
└───personal-projects
│   └───my-cool-project
│       │   index.html
│       │   ...
└───work-projects
│   └───my-professional-project
│       │   index.html
│       │   ...

Now let's set our global config, this will create a file for the personal account:

git config --global user.name "nizar"
git config --global user.email "nizar-personal@email.com"

Let's check the personal config:

git config -l

You should be able to see what we have just set above.

Now let's do a little demo to verify our personal configuration:

As you can see I've created a directory for my personal project and initialized a Git repository within a project folder, looking at the Git log we can my personal info being applied.

Now since this is sorted out, Let's configure our work/professional account, but before we start I want you to take a look at the root directory for a file called .gitconfig.

We will be modifying this file and be creating a new similar one.

Modify the .gitconfig file:

[user]
	name = nizar
	email = nizar-personal@email.com

[includeIf "gitdir:/home/nizar/work-projects/"]
	path = /home/nizar/.gitconfig-work

As you noticed we added an IF statement, telling Git if it is in our work-projects directory (which we will be creating next) use the .gitconfig-work configuration instead of the global one.

Create the work-projects directory:

mkdir /home/nizar/work-projects

Create the .gitconfig-work file next to the old one:

nano /home/nizar/.gitconfig-work

The content will be similar in structure, adapt as needed:

[user]
        name = nizar-work-name
        email = nizar-work@email.com

Again, let's do a demo of this work account/configuration:

Note: user and host names are a bit different, it was a mistake on my part, but the image should represent the point without a problem.

As you can see, the work configuration is applied in this directory instead of the global personal configuration.

Conclusion

Applying the above steps, it's safe to say that we are done with our multiple Git accounts setups.

As always, I hope you learned something.

Found this useful? feel free to share it with your friends.

Join the newsletter from here to notify you of new posts and updates.

Like the post? consider buying us a coffee ❤️.

Having an exposed server in the wild is scary where people try to get into our servers and start abusing them.

In this post, we will cover the must-do procedures to harden and secure our Linux servers.

Table of contents

• Requirements
• Packages Updates
• Users
• Accessing The Server
• More on SSH
• The Firewall
• Conclusion

Requirements

• Basic understanding of Linux and the command line

Packages Updates

We all have a number of packages or apps installed and running in our systems and it's very important to update them regularly not just for the better performance and the features an update might introduce (don't be mistaken updates with upgrades, they might not be compatible with the ecosystem you have) but also for the security patches the developer's ship to us to fix vulnerabilities.

That's why regular updates are good but what if I told you they can be automated?

Great right, Automatic updates are not recommended for various reasons and what's recommended is to read the changelog for each update we would install to make sure it doesn't break our servers, however, security updates/patches are recommended to be installed, below we will see how to make them automatic.

We will be using the unattended-upgrades package, we can install it with the following command:

sudo apt install unattended-upgrades

After installing it, run the following:

sudo dpkg-reconfigure --priority=low unattended-upgrades

This will bring a dialog, Choose YES and it will create the following config file:

/etc/apt/apt.conf.d/20auto-upgrades

Having this content

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

We can further configure this tool to update and upgrade other stable packages or just security updates, just edit the following file:

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

You will find something similar to this

# head /etc/apt/apt.conf.d/50unattended-upgrades

// Note that in Ubuntu security updates may pull in new dependencies
// from non-security sources (e.g. chromium). By allowing the release
// pocket these get automatically pulled in.
Unattended-Upgrade::Allowed-Origins {
	"${distro_id}:${distro_codename}";
	"${distro_id}:${distro_codename}-security";
	// Extended Security Maintenance; doesn't necessarily exist for
	// every release and this system may not have it installed, but if
	// available, the policy for updates is such that unattended-upgrades
	// should also install from here by default.
	"${distro_id}ESMApps:${distro_codename}-apps-security";
	"${distro_id}ESM:${distro_codename}-infra-security";
//	"${distro_id}:${distro_codename}-updates";
//	"${distro_id}:${distro_codename}-proposed";
//	"${distro_id}:${distro_codename}-backports";
};

It's well documented so you won't find trouble configuring it.

And like this, we are installing security updates automatically providing some peace of mind.

Users

The first thing we hear in any blog or forum is to don't use the root user or its privileges as much as possible, so it's recommended to use a non-root user.

Create a user with the following command:

sudo adduser MY_NAME

Add the user to the sudo group  to get its privileges on-demand:

sudo usermod -aG sudo MY_NAME

That's it, log out of this session and connect with this user.

Accessing The Server

There are various ways to access a Linux server, using VNC and/or SSH are common.

VNC by nature is not secure since its traffic is not encrypted but on the other hand, SSH is, and it's hard to break throw.

That's why I recommend using SSH as your only way to the server and SSH itself can be even more secure following the next steps:

Use keys to authenticate and not password, Let's create a private key (in your client/machine terminal not in the server):

ssh-keygen -t rsa -b 4096 -C "MY_NAME's server private key"

This command will generate 2 files, id_rsa and id_rsa.pub (the private and public key respectively).

Add your public key to the server (in most cases the path to the keys are in ~/.ssh directory):

ssh-copy-id -i /path/to/id_rsa.pub MY_NAME@IP_OF_SERVER

Now you can use it to authenticate and access the server:

ssh -i /path/to/id_rsa MY_NAME@IP_OF_SERVER

You will be prompted to enter your key password, when done you will get into the server safely.

More on SSH

In case you don't or won't use IPv6 for SSH you can disable it to reduce the number of ways SSH can accept communications.

Open the following file:

sudo nano /etc/ssh/sshd_config

And change the AddressFamily property to inet:

From 'AddressFamily any' to 'AddressFamily inet' # Which means IPv4 only

Root access, you can disallow SSH root access:

From 'PermitRootLogin yes' to 'PermitRootLogin no'

And since we are using keys to authenticate, disallow password authentication:

From 'PasswordAuthentication yes' to 'PasswordAuthentication no'

Finally, Restart the SSH daemon for changes to take effect:

sudo systemctl restart sshd

The Firewall

Open ports are just a nightmare it's like having a house with no locked doors, you can imagine.

A firewall is basically a set of rules to control incoming and outgoing requests in your server, now when it comes to configuring the firewall in Linux using iptables; its a pain, that's why there is a package called ufw (which stands for 'Uncomplicated Firewall'), Let's install it and configure it.

Install ufw:

sudo apt install ufw

Since we are using SSH it listens on port 22 so we will have to allow communications through that port:

# Before doing anything, Reset any rule (Make sure it wasn't used by anyone before)
sudo ufw reset

# Enable UFW
sudo ufw enable

# Allow OpenSSH server (SSH)
sudo ufw allow 22

Now before we wrap the firewall step, Again if you are not going to use IPv6, block it using ufw too, Let's do it (it's optional).

Open the following file:

sudo nano /etc/default/ufw

Change the IPv6 property:

From 'IPV6=yes' to 'IPV6=no'

Now we can disable and enable ufw again for changes to take effect:

sudo ufw disable && sudo ufw enable

Verify the changes:

sudo ufw status verbose

And remember if you are going to host a website or an API, you will need to open port 80 (HTTP) and/or 443 (HTTPS).

Conclusion

After all the steps we have taken, we can call it a day hardening our Linux server.

As always, I hope you learned something.

Found this useful? feel free to share it with your friends.

Join the newsletter from here to notify you of new posts and updates.

Like the post? consider buying us a coffee ❤️.

Apt-Cacher-NG is a write-through caching proxy that caches apt repositories metadata and packages for other hosts connected to it, the proxy is mostly used on the same network of the hosts to speed things up.

In this post, we will be building the Docker image and running the apt-cacher-ng server along with configuring the clients to use it as their apt caching proxy.

Table of contents

• Requirements
• Do We Need a Proxy?
• Why Use It Inside a Docker Container?
• Setup Dockerfile
• Dockerfile Breakdown
• What is PassThroughPattern?
• Setup Docker Compose file
• Start and Verification
• Clients Setup
• Setup Verification
• Conclusion

Requirements

• Docker
• Docker Compose
• A text editor of your choice

Do We Need a Proxy?

The main use case is having multiple machines running systems that use apt as their package manager, where you want to speed up the process of updating and upgrading metadata and packages.

Why Use It Inside a Docker Container?

Mainly for the idea of isolating the host from the apps running on it and the ease of management of those apps, Docker fits perfectly for this.

Setup Dockerfile

In order to run the proxy in a Docker container, we need first to create a Dockerfile for it.

Let's start by creating a directory for the Docker file:

mkdir custom-apt-cacher-ng

Get into the directory and create the file:

cd custom-apt-cacher-ng && touch Dockerfile

Paste the following content into it:

FROM ubuntu:21.04

# Expose the cache directory for volume binding
VOLUME ["/var/cache/apt-cacher-ng"]

# Update apt-get cache
RUN apt-get update -y && \
        # Install apt-cacher-ng package
        apt-get install apt-cacher-ng -y && \
        # Clean up
        rm -rf /var/lib/apt/lists/*

# Expose the apt-cacher-ng port to be binded
EXPOSE 3142

# Set cache directory permissions
CMD chmod 777 /var/cache/apt-cacher-ng && \
        # Append PassThroughPattern config for SSL/TLS proxying (optional)
        echo "PassThroughPattern: .*" >> /etc/apt-cacher-ng/acng.conf && \
        # Start the service
        /etc/init.d/apt-cacher-ng start && \
        # Output all logs of apt-cacher-ng
        tail -f /var/log/apt-cacher-ng/*

Dockerfile Breakdown

Let's explain this Dockerfile, we see that we are based on a stable version of Ubuntu with version 21.04 and, exposing the caching directory to be used for persistence, and running the main command which is installing the apt-cacher-ng package itself, then exposing the port the package uses, and finally, we are setting up permissions and appending the PassThroughPattern (we will get to this below) before starting the service.

What is PassThroughPattern?

This config allows us to proxy/tunnel everything including the secured repositories via SSL/TLS throw the apt-cacher-ng server, keep in mind that it will not cache the secured ones since the traffic is encrypted.

Setup Docker Compose file

Let's set up the Docker Compose file, now this is an optional part but it's very recommended.

Create the file in the same root directory:

touch docker-compose.yml

Paste the following content into it:

version: "3"

services:
  app:
    build: .
    image: custom-apt-cacher-ng
    container_name: apt-cacher-ng
    restart: unless-stopped
    ports:
      # To connect to apt-cacher-ng from outside of local host, change 127.0.0.1 to 0.0.0.0 or whatever interface you want
      - 127.0.0.1:3142:3142
    volumes:
      - ./cache:/var/cache/apt-cacher-ng

This Docker Compose file will expose the 3142 port (feel free to change it to whatever you want) and bind the local directory cache in the host for the apt-cacher-ng caching directory.

Start and Verification

We can start the proxy in two ways, Docker or Docker Compose, we will cover both of them below.

The Docker way

Build the proxy image:

docker build -t custom-apt-cacher-ng .

Run an instance of that image in detached mode:

docker run -d -p 127.0.0.1:3142:3142 --name apt-cacher-ng custom-apt-cacher-ng

Now the container should be running, to verify run:

docker ps -a | grep "custom-apt-cacher-ng"

The Docker Compose way (recommended)

Build the proxy image:

docker-compose build

Run the service using:

docker-compose up -d

You can verify that the container is up using the same command as above.

We are done setting up the proxy, the next step will be setting up the clients to use the cache proxy.

Clients Setup

We can use the host where the server lives as a client for the proxy too, and that's what we will be doing here as a first step.

Create an apt proxy file:

sudo touch /etc/apt/apt.conf.d/01proxy

Paste the following in the proxy file

Acquire::http { Proxy "http://SERVER_IP:3142"; };

Make sure to change the SERVER_IP before saving (It will be localhost or 127.0.0.1 in this client setup).

Now before we start installing packages with the proxy we need to reset the apt lists and cache.

Execute the following commands each at a time:

sudo apt-get clean
cd /var/lib/apt
sudo mv lists lists.bak # or delete it, preferred to keep a backup
sudo mkdir -p lists/partial
sudo apt-get clean
sudo apt-get update

That's it, we are done setting up the server and the client for the proxying process.

Setup Verification

Let's verify that the setup is working via a simple sudo apt-get update, then head to http://localhost:3142/acng-report.html and we should see some content being downloaded and cached for the next requests.

Conclusion

We just set up the apt proxy using either Docker or Docker Compose with ease, and we tested the setup using the local host.

GitHub - razinj/docker-custom-apt-cacher-ng: Docker image for apt-cacher-ng that allows SSL/TLS proxying along with exposing the cache volume

Docker image for apt-cacher-ng that allows SSL/TLS proxying along with exposing the cache volume - GitHub - razinj/docker-custom-apt-cacher-ng: Docker image for apt-cacher-ng that allows SSL/TLS pr...

GitHubrazinj

As always, I hope you learned something.

Found this useful? feel free to share it with your friends.

Join the newsletter from here to notify you of new posts and updates.

Like the post? consider buying us a coffee ❤️.