DEV Community: Andrea Cappuccio

Docker CMD vs ENTRYPOINT: explaining the difference

Andrea Cappuccio — Sat, 26 Jun 2021 11:24:31 +0000

We IT people LOVE tinkering with new tech stuff, and Docker is no exception. As a matter of fact, Docker was ranked as the #1 most wanted platform, #2 most loved platform, and #3 most broadly used platform in the 2019 Stack Overflow Developer Survey, and #1 most wanted platform, #2 most loved platform and #3 most popular platform in the 2020 edition of the same survey.

If you've bumped into this article, chances are that you have been bamboozled by the ~~fruit doggo~~ difference between the CMD and ENTRYPOINT instructions defined in a Dockerfile, used to describe how a Docker container should be run.

But what's a Docker container?

Containers are lightweight, standalone, executable packages of software designed for running specific tasks, no matter if short-lived or long-running. Therefore, a container's lifecycle depends on the ongoing process inside of it.

Once the process stops, the container stops as well.

Ok, but what role is our Dockerfile playing here?

Containers are dependent on images and use them to construct a run-time environment in order to run an application. A Dockerfile is a script which role is to define the process which leads to the creation of a final image, and how to run a container bound to said image.

The process of creating a Docker image usually begins with a FROM command, defining a base image to build our image upon. We usually follow up with a bunch of RUN instructions, used to run commands which modify the underlying filesystem.

Each RUN instruction creates a new image layer that contains a modification to the filesystem.

Fine. Now what about the CMD vs ENTRYPOINT stuff?

CMD and ENTRYPOINT are two different types of instructions used to define how a Docker container should be run.
Let's dive into the details of each one:

CMD

A CMD instruction defines the default command used to run a Docker container from an image.

Given a simple image like the following:

FROM alpine
CMD ["echo", "Hello, World!"]

Running it with:

docker container run my-container

Will yield the following result:

Hello, World!

A Dockerfile can contain multiple CMD instructions, but every single one of them, except for the last one, will be ignored.

A CMD instruction can be overridden by the arguments passed to docker container run, like:

docker container run my-container echo "Hello again!"

Will yield:

Hello again!

ENTRYPOINT

ENTRYPOINT instructions define, just like their CMD siblings, the default command used to start a container.

FROM alpine
ENTRYPOINT ["echo", "Hello, World!"]

Will yield:

Hello, World!

Cool, so... what's the difference at this point?

Well, the main difference is that, if both a CMD and ENTRYPOINT instructions are defined inside a Dockerfile, the CMD instruction will be concatenated to the ENTRYPOINT one:

FROM alpine
ENTRYPOINT ["echo"]
CMD ["Hello, World!"]

Wil lead to us seeing:

Hello, World!

Also, while CMD instructions are, by design, made do be easily overridden by passing arguments to docker container run commands, ENTRYPOINT have purposely been made harder to override manually, by forcing user to use a --entrypoint flag.

This leads us to a pattern

This design leads us to a consistent pattern. And we like patterns, patterns are good for our mental health:

We can use ENTRYPOINT to define a base command which always gets executed, and CMD to define default arguments for this command, easily overridable by passing custom args to docker container run.

Listing all the possible values for an enum in Typescript

Andrea Cappuccio — Fri, 29 Jan 2021 16:28:43 +0000

Today I have spent quite a few hours trying to contribute a P.R. to a project I really like, and often use in my day-to-day work, the excellent class-validator.
The problem I was trying to solve consisted in listing the possible values for a given enum, in order to let class-validator print them in its enum-related error messages.

The main problem is that enums get transpiled di

When values are not specified, an incremental integer is assigned to each key, so the transpiled JS looks like the following:

// Before
enum Steak {
    Medium,
    Rare,
    WellDone
}

// After
var Steak;
(function (Steak) {
    Steak[Steak["Medium"] = 0] = "Medium";
    Steak[Steak["Rare"] = 1] = "Rare";
    Steak[Steak["WellDone"] = 2] = "WellDone";
})(Steak || (Steak = {}));

When an inteer number is assigned as the value, it is simply assigned instead of the deafult incremental integer in the example before.

When a string value is assigned, though, the transpiled JS code looks a bit different:

// Before
enum Steak {
    Medium = "MEDIUM",
    Rare = "RARE",
    WellDone "WELL_DONE"
}

// After
var Steak;
(function (Steak) {
    Steak["Medium"] = "MEDIUM";
    Steak["Rare"] = "RARE";
    Steak["WellDone"] = "WELL_DONE";
})(Steak || (Steak = {}));

These transpilation differences lead to obvious inconsistencies when attempting to retrieve an enum's list of possible values when using the common Object.values(), Object.keys() and Object.entries() methods. By fiddling with an heterogeneous enum like the following:

enum TestEnum {
    a = 'aA',
    b = 'bB',
    c = 1,
    d = 2,
    e = '01'    
}

The following conclusions can be drawn:

Object.values() returns an array containing all the possible values for the given enum AND the keys for the properties which have integer numbers as values ([ 'c', 'd', 'aA', 'bB', 1, 2, '01' ])
Object.keys() returns an array containing all the enum's keys plus all of the integer values defined ([ '1', '2', 'a', 'b', 'c', 'd', 'e' ])
Object.entries() returns an array of [key, value] arrays, plus N [value, key] entries for N of the enum's properties which have integer numbers as values ([ [ '1', 'c' ], [ '2', 'd' ], [ 'a', 'aA' ], [ 'b', 'bB' ], [ 'c', 1 ], [ 'd', 2 ], [ 'e', '01' ] ])

So, finally, the solution I came up with is:

Object.entries(TestEnum).filter(entry => !parseInt(entry[0])).map(entry => entry[1])

Which starts from Object.keys()'s results, filtering out all the redundant [value, key] entries.

Handling multiple Git credentials the easy way

Andrea Cappuccio — Sat, 25 Jul 2020 15:42:07 +0000

In this post I'm gonna quickly go over a nice and clean setup I use to manage authenticating with different accounts on a variety of different project repositories hosted on cloud services such as GitHub, GitLab, BitBucket, etc..

PREPARATION

As a first step, we want to make sure that all of our accounts use SSH keys to authenticate connections between our machines and the cloud providers. Nowadays the process doesn't require much fiddling, and can be simply done using our providers' web UIs. I won't go over this part because the specific way to set this up would be vendor-specific, and I don't consider this step to be complicated enough to require any explanation.

Let's suppose that at this point we own two different GitLab accounts, each bound to a dedicated SSH key stored on our machine:

user: first
email: first@myemail.com
private key: ~/.ssh/first/id_rsa
public key: ~/.ssh/first/id_rsa.pub
repository name: first-project

user: second
email: second@myemail.com
private key: ~/.ssh/second/id_rsa
public key: ~/.ssh/second/id_rsa.pub
repository name: second-project

Configuring SSH

If not present, a SSH configuratio file needs to be created

cd ~/.ssh/
touch config

We are going to use said file to tell our machine to use different credentials depending on the host we're trying to connect it to.

This could lead us to a question:

We just assumed both our accounts are gitlab.com accounts. How do we use different credentials if the host is the same?

The answer is straightforward:

ssh can be configured by using host alias names, which will basically allow us to treat the same underlying hostname as two different hosts, while still resolving the correct hostname.

Let's see how to take advantage of this feature

# Gitlab.com - "first" account
Host gitlab.com_first   # <-- this could be any alias 
    HostName gitlab.com 
    User git
    Preferredauthentications publickey
    IdentitiesOnly yes
    IdentityFile ~/.ssh/first/id_rsa

# Gitlab.com - "second" account
Host gitlab.com_second  # <-- this could be any alias 
    HostName gitlab.com
    User git
    Preferredauthentications publickey
    IdentitiesOnly yes
    IdentityFile ~/.ssh/second/id_rsa

Configuring Git

Our job is pretty simple now: we need to let git use our alias hostnames in order to provide the correct SSH credentials when trying to authenticate (using only our "first" account for brevity):

# If the remote repo is still not cloned locally
# we just need to provide our alias hostname
# when cloning
git clone git@gitlab.com_first:first/first-project.git

# If the remote repo is already cloned locally
# we need to update the remote's hostname. Here
# we're assuming "origin" its name.
git remote remove origin
git remote add origin git@gitlab.com_first:first/first-project.git

DONE

We're done with our configuration, now the correct credentials will be used when connecting to each remote.

NextJS + TypeScript + TailwindCSS + Storybook project setup

Andrea Cappuccio — Tue, 14 Jul 2020 15:15:04 +0000

TUTORIAL BASED ON STORYBOOK v5, ON v6 EVERYTHING STORYBOOK-RELATED WORKS OUT OF THE BOX!

Following is a simple guide to get up and running with the NextJS+TypeScript+TailwindCSS+Storybook combination, a task which took me a lot more time than I originally estimated, due to the unexpected lack of specific guides on how to deal with this particular scenario plus the sparse nature of the information I had to look up to set everything up as desired.

NEXTJS SETUP

yarn create next-app

That's it. Done. A fully-functional NextJS app will be created using the official starter kit.

TAILWINDCSS SETUP

yarn add -D tailwindcss postcss-preset-env to install the TailwindCSS library and some useful PostCSS polyfills
npx tailwind init to generate a tailwind.config.js file.
Edit the TailwindCSS configuration file we just created to enable and configure the built-in CSS purging process. (Notice how I'm using the ".tsx'" extension here, since I already know I'm going to use TypeScript for this project)

module.exports = {
  purge: ['./components/**/*.tsx', './pages/**/*.tsx'],
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}

Create postcss.config.js to configure PostCSS in a minimal way, like the following

module.exports = {
  plugins: [
    "tailwindcss", 
    "postcss-preset-env"
  ]
};

Create /styles/index.css and populate it using the postcss-import-friendly @import directives (instead of using @tailwind)

@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";

TYPESCRIPT SETUP

yarn add --dev typescript @types/react @types/node
touch tsconfig.json
yarn next to start NextJS, which will automagically recognize our newly created tsconfig.json and inject a valid configuration json into it
Create a /pages/_app.tsx file

import React from "react";
import "../styles/index.css"; // <- applied everywhere in the NextJS application scope

const MyApp = ({ Component, pageProps }) => {
  return <Component {...pageProps} />;
};

export default MyApp;

STORYBOOK SETUP

yarn add @storybook/react babel-loader @babel/core awesome-typescript-loader react-docgen-typescript-loader -D
mkdir .storybook
cp ./tsconfig.json ./.storybook/
Edit /.storybook/tsconfig.json to suit your Storybook-TypeScript integration

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": false,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "react"            // <- important!
  },
  "exclude": ["node_modules"],
  "include": [                // <- important!
    "../types.d.ts",
      "../next-env.d.ts",
      "../**/*.stories.ts",
      "../**/*.stories.tsx"
    ]
  }

Create /.storybook/main.js and feel free to copy the following configuration

const path = require("path");

module.exports = {
  stories: ["../components/**/**/*.stories.tsx"],
  webpackFinal: async (config) => {
    config.module.rules.push({
      test: /\.(ts|tsx)$/,
      use: [
        {
          loader: require.resolve("awesome-typescript-loader"),
          options: {
            configFileName: path.resolve(__dirname, "./tsconfig.json"),
          },
        },
        /* 
          ** OPTIONAL ** 

          Basically a webpack loader  used to                
          generate docgen information from TypeScript React components. 
The primary use case is to get the prop types 
table populated in the Storybook Info Addon.
        */
        {
          loader: require.resolve("react-docgen-typescript-loader"),
          options: {
            tsconfigPath: path.resolve(__dirname, "./tsconfig.json"),
          },
        },
      ],
    });

    config.resolve.extensions.push(".ts", ".tsx");

    return config;
  },
};

create /.storybook/preview.js and use it to import our stylesheet as follows

// The preview application is essentially just your stories with 
// a framework-agnostic 'router'. 
// It renders whichever story the manager application tells it to render.
// In this case we just use it to import the stylesheet and inject it 
// in the context of our stories

import "../styles/index.css";

Update postcss.config.js to use an object-based format. This is super important in order to solve any issues Storybook's webpack process may encounter while resolving the dependencies!

module.exports = {
  plugins: {
    tailwindcss: {}, 
    "postcss-preset-env": {}
  }
};

DONE

Now you will be able to create your component stories in your own component's folders (ex.: /components/button/1-button.stories.tsx) using this powerful toolset.

P.S.: If you wish to organize your Storybook stories using a different folder structure, you'll need to do no more than editing the stories property inside the exported configuration in /.storybook/main.js using your desired glob patterns