DEV Community: Manuel Castellin

SnykCon - Making Sense of Container Security with Snyk CLI and GitHub Actions

Manuel Castellin — Thu, 22 Oct 2020 19:51:27 +0000

I'm so excited I've participated in SnykCon 2020! 🔥
Listening to the talks lit a fire in me, and I really want to take container security seriously from now on, knowing how much easier it is today with tools like Snyk 🚀

But after running a container scan...

... on a couple of very simple projects, well, this is not the result I was expecting: 🤯🤯🤯

This was literally an "Hello World!" type of project, what is going to happen if I scan a real project? How do I start making sense of this?

Let me do a quick introduction and then I'll show you how I practically approached this problem 😉

A modern approach to security - DevSecOps

As I learned from this year's conference, finding vulnerabilities early on in the software development cycle is paramount in this day and age.

With the adoption of Continuous Delivery, hence shorter release cycles, we can no longer afford to wait for a team of security experts to validate every release. New code will already be running in production by the time they complete their audit!

Also, developers are the best people that can contextualize the vulnerabilities, and take action to fix them. 👨🏻‍💻

Shifting the responsibility towards developers

Ok, this is a nice concept, developers are now responsible for security too! But hold on a sec, they're developers! How can we expect them to do their job, and also monitor their software for vulnerabilities every day?

This is where I think people at Snyk have done a great job. Their tools are focused on helping developers with:

identifying vulnerabilities as early as in the developer's laptop
providing command-line tools that can be integrated into CI/CD workflows
monitoring generated artifacts to proactively notify the team when new vulnerabilities are discovered
advise on actions to fix vulnerabilities directly in the CLI for developers to see

My experience with Snyk Container scan

Given that there's no such thing as absolute security, this is the process I followed to get as close as I could for my demo container.

If you want to have a look at the repository, you can find it here. It's a simple "Hello, World!" Python project, that, when I started, had a whopping 267 vulnerabilities!

Step 0 - creating a Snyk account

The first thing to do is to create a Snyk account. This is required to start using the CLI tools from your development machine. See below, you just need to authorize the app with one of your existing accounts

After creating the account, Snyk will generate your personal API token. This is needed to use the CLI tools from command-line and from your CI/CD workflow.

If you already have an account, you'll find the token under Your Name > General Settings > API Token

Install the CLI tools with npm and authenticate with your token:

# Install Snyk CLI with npm
> npm install -g snyk

# Authenticate with your Snyk account
> snyk auth ${YOUR_API_TOKEN}

We're now ready to scan our project! 🚀

Step 1 - start from the development machine

As I learned in the conference, the best way is to start in your development machine using Snyk CLI.

First I wanted to make sure my python dependencies are clean from vulnerabilities. I'll do that directly from the command-line by running

> snyk test

And it immediately found an issue with my requirements.txt file.

What's cool about this, is that Snyk tells me that the vulnerability in sqlalchemy@1.3.17 has been resolved in a later version of the package, so I will just upgrade it to the suggested version sqlalchemy@1.3.19.

Container image scanning

Next, I want to run a container scan to make sure my image has as little vulnerabilities as possible.

To do that, I first need to build the image, and then I can immediately scan it from the command line with snyk container test:

> snyk container test --file=Dockerfile snyk-container-demo

By using the --file=Dockerfile we can tell Snyk which Dockerfile generated the snyk-container-demo image. This way we'll be able to get more accurate suggestions from the advisor.

And then I started to cry 😭

Stay calm and keep reading

This is what I told myself when I first read this report. Despite having soo many issues reported (267 to be exact), the report is also suggesting alternative images to the one I am currently using for the project:

Recommendations for base image upgrade:

Alternative image types
Base Image                  Vulnerabilities  Severity
python:3.9.0rc1-slim        73               17 high, 12 medium, 44 low
python:3.9.0b5-slim-buster  73               17 high, 12 medium, 44 low

This is pretty nice! I can see that the -slim and -slim-buster versions of my base image have fewer vulnerabilities. So next thing I'll do is changing my Dockerfile to use one of those.

And after applying the suggestion...

... I was glad to see that the number of vulnerabilities found was drastically reduced!

In this report, Snyk is also telling me that I'm currently running on the most secure version of the selected base image, remember, there's no such thing as absolute security 😅

Being happy with the base image I selected, I can commit the changes in the repo and move on with the process.

Step 2 - CI Integration

I will now integrate Snyk with my Continuous Integration workflow. I don't have any in this project yet, so I'm going to use GitHub Actions.

With a quick Google search, I found out that Snyk already published a GitHub action I can use to scan my repository on every commit and collect the results in the Security tab of the GitHub repo.

I will then copy the template provided, and create a new file in my repo in the .github/workflows directory called secscan.yml:

name: Container Scan
on: push
jobs:
  snyk:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Build the Docker image
      run: docker build -t mcastellin/snyk-container-demo .
    - name: Run Snyk to check Docker image for vulnerabilities
      # Snyk can be used to break the build when it detects vulnerabilities.
      # In this case we want to upload the issues to GitHub Code Scanning
      continue-on-error: true
      uses: snyk/actions/docker@master
      env:
        # In order to use the Snyk Action you will need to have a Snyk API token.
        # More details in https://github.com/snyk/actions#getting-your-snyk-token
        # or you can signup for free at https://snyk.io/login
        SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      with:
        image: mcastellin/snyk-container-demo
        args: --file=Dockerfile --exclude-base-image-vulns
    - name: Upload result to GitHub Code Scanning
      uses: github/codeql-action/upload-sarif@v1
      with:
        sarif_file: snyk.sarif

I have pretty much used the standard values here, except for the args: --file=Dockerfile --exclude-base-image-vulns.

By adding the --exclude-base-image-vulns parameter we are telling Snyk not to report vulnerabilities that are introduced by Docker base image layers. This is to make sure that we are breaking the build only when we introduce new issues in the Dockerfile.

The reason for ignoring base image vulnerabilities is to avoid having too much noise in the CI scan. We have already accepted the base image so we're only interested in blocking the issues we add with our customizations.

Before committing our GitHub Action YAML file, we have to configure the secret.SNYK_TOKEN in our registry. In the GitHub repository settings, go to Settings > Secrets > New Secret and configure the value for the Snyk token:

We can now push our changes and see the result of the security scan:

Step 3 - Breaking the build

After all the effort fixing vulnerabilities I really want to make sure nobody can introduce new ones! Let's modify our Dockerfile and open a Pull Request that introduces an insecure package: curl, who knew!? 🤔

...

RUN apt-get update \
    && apt-get install -qqy curl \
    && rm -rf /var/lib/apt/lists

...

Found it!

And the container scan found new vulnerabilities, giving us the peace of mind, that if anyone installs dodgy packages we'll be able to catch it before merging the code into the main branch!

Step 4 - Analyzing the report

For every issue found by Snyk you'll get a very detailed report, telling you:

what file introduced the issue
a description of the vulnerability
remediation advice

Wrapping up

It's been a fun couple of days for me to attend to SnykCon 2020 and I hope by sharing my first experience with Snyk and container scanning, I have also encouraged you to learn how to make the most out of these tools to keep your applications secure!

Thanks for reading! And don't forget to follow me if you want to see more content like this!

Use Docker with Proxy Servers Tutorial

Manuel Castellin — Fri, 16 Oct 2020 17:59:11 +0000

If you ever tried to run Docker in a corporate network then you know what I'm talking about. To prevent potential intrusions, infrastructure engineers force all internet traffic to go through proxy servers, sometimes making it extremely difficult to run even the simplest thing.

Why should you read this article?

With this tutorial, you'll learn everything there is to know on how to configure proxies for Docker engine and containers!

configure proxy servers in Docker for Desktop
configure proxy servers with Linux & Systemd
use proxy servers with running containers

Let's get started! 🚀

Quick refresher: what is a Proxy server?

A proxy server is simply a server that sits in between your machine and the Internet, that can interact with the outside of your network on your behalf.

The main reasons why you would want to use a Proxy are the following:

To improve network performance by caching internet content
As an additional layer of security by implementing additional encryption, protect against DoS attacks, blacklist dangerous sites, and much more
For auditing and logging purposes, many companies need to track who and when access mission-critical systems

How Docker uses proxies

One thing that was very confusing for me at first, is that Docker daemon and Docker containers don't share the same proxy configuration!

Settings for Docker engine

Your Docker engine needs to connect to the internet to access image registries and pull/push container images.

If your settings are not correct you will typically see errors when trying to use docker login or pulling images from DockerHub, see below for example:

Setting a Proxy on Docker for Mac/Windows

If you're running Docker for Desktop this is a really simple operation. You can do this from Docker's settings Docker > Preferences > Resources > Proxies. All you need to do is provide values for the following variables:

HTTP_PROXY: the proxy server endpoint to handle HTTP calls
HTTPS_PROXY: the endpoint to handle HTTPS calls (notice this doesn't have to be an https endpoint)
NO_PROXY: a list of hosts that Docker can reach without using the proxy (usually you'll see localhost,127.0.0.1 in this field

After this, you should click the Apply & Restart button, and you'll be able to push/pull images ✅

Using authentication

One question I get asked a lot is how to provide authentication if this form does not have a username and password field. I am not sure why they didn't include such fields in the configuration, but you can just use URL authentication like this:



http://<username>:<password>@my.proxy.com:3128/

Setting a Proxy on Linux with Systemd

If you're working with a Linux installation, you won't have access to some nice Preferences menu. In Linux, the Docker engine is configured as a system service with Systemd.

Let's dust off our System Administration skills! 👨🏻‍💻

In most Linux distributions, Docker is configured as a service with Systemd. You can alter the service configuration by creating an override file. Follow these simple steps:

1) Edit the Docker service configuration with:



> sudo systemctl edit docker.service

Systemd will open (or create) the service override file with your default terminal editor.

2) Add or modify the service configuration to include proxy variables. Your service file should look like this:



[Service]
Environment=“HTTP_PROXY=http://10.0.1.60:3128”
Environment=“HTTPS_PROXY=http://10.0.1.60:3128”
Environment=“NO_PROXY=localhost,127.0.0.1”

3) Save and close the file, and restart Docker with



> sudo systemctl restart docker.service

Running containers with proxy settings

Now that you set up proxies for Docker engine, you need to understand that Docker will never share those settings with running containers! 👎🏻

If you want your containers to access the internet, you'll need to supply Proxy settings using environment variables like this for example:



> docker run </span>

    --env http_proxy="http://my.proxy.com:3128" </span>

    --env https_proxy="http://my.proxy.com:3128" </span>

    nginx sh -c "curl google.com"

Full Step-By-Step Tutorial

Take a look at my video below to see everything I described in the article in a real environment!

In the video, I'll also explain how you can configure Docker to use proxy configuration for containers by default? This way you won't have to pass http_proxy and https_proxy variables every time.

Productivity? Yes, please! 🚀

Don't forget to follow me for more content like this!

Hacktoberfest - Ideas for Contributing as a Beginner

Manuel Castellin — Thu, 01 Oct 2020 22:16:45 +0000

First day into Hacktoberfest! Yay! And I'm already freaking out about it! 🤪

It was fun publicly committing to make four OpenSource contributions in the next month, but then reality kicked in.

For beginners, it's really hard to find issues they can work on. Especially if it's their first time trying to get into OpenSource. Thirty days is not a long time for

finding a project that picks your interest
learning the codebase
make contributions
have them approved.

As someone that never made significant contributions before, I feel I have to think outside the box if I want this to be a good experience and become part of my life as a programmer even after the event.

My personal dilemma with Hacktoberfest

As a Software Engineer, I want to learn as much as I can about Containers and DevOps, so the ideal project for me would be something related to Docker or Kubernetes or any other related software like Prometheus or Helm.

Problem is, I am not a Go developer, and the entire ecosystem is written in Go! So even though I'm a hardcore user of these tools, I cannot possibly think that I'll be able to make four significant code contributions in one month. 🤯

Creative Ways to Contribute

Of course, the logical way is contributing to code, although it's not easy to start with. It takes skills that cannot be acquired in a few days, and you don't want to be spamming maintainers with Pull Requests that are half baked (always respect other people's time, that's my motto!). So I can think of these additional ways beginners (like myself) can contribute successfully. Let's dive in!

Documentation & Knowledge Base

There's always a need for documentation. If you like writing and you're detailed oriented, this will be a great way for you to contribute.

When you search for issues try to click the filter option and search for labels that contain the word documentation or docs and see if there's anything urgent that needs attention. Maintainers will welcome a good piece of documentation any day!

READ, READ, then READ MORE!

Have documentation for breakfast, lunch and dinner. Pick a topic you know very well, and go through the documentation pages for that topic. I can guarantee you'll find something you can improve using the knowledge you acquired with years of hard work.

README.md

How was your experience when starting out with the project? Did you find everything you needed in the README.md file or you had to figure things out by yourself?

If the latter is true, can you improve the README file for other aspiring contributors?

Graphic Design

Every awesome OpenSource project needs graphics to use in their:

Documentation pages
README files
Websites
T-shirts
Stickers
the list goes on...

If your passion is creating graphic elements, reach out to the project maintainers and ask them if they need new icons or maybe design a funny 404 or 500 page (it is always nice to laugh with Internal Server Error pages like the one above 😛).

Translate

Everyone is special, yes, you too! Just because you're alive you must be fluent in at least one language. Use your gift! Search for translation issues, create content in your mother tongue to help the project expand its reach and get even more people interested in the mission!

Educate

Who doesn't love a good tutorial? Do you love teaching others how to do things? This can be the value you bring to the project.

Record a video to show how you installed the software in a particular operating system or showcase one of the hottest features to encourage people to "star" ⭐️ the project. These videos can then be embedded in the README.md with Markdown as I did in one of my repositories

[![K8s Autoscaling](/media/K8s_Autoscaling.gif)](https://raw.githubusercontent.com/mcastellin/udacity-operationalize-microservice/master/media/K8s_Autoscaling.mp4)

Some projects have example repositories!

You might find that the project you're interested in has a separate repo on GitHub to store configuration examples or templates to help people get started. See for example Helm Charts or AWS CloudFormation Templates!

Do you have work experience with the technology? Look back at your past projects, see if there's anything reusable you can share with the world! (It's a good idea to first check with your employer if you're allowed to do so 😅)

Organize Notes

Interest Groups are most likely organising weekly meetings to discuss new bugs, collect ideas, plan future meetings and so on.

You can actively participate in those meetings and offer your services to summarise the points discussed and distribute meeting's minutes via email, IM or even include them in the repo's Wiki pages!

Test & Bug Report

Developers can't test features with every existing operating system or mobile phone. Keep a close watch on new feature releases or bug fixes and be eager to test them yourself. Then reach out to developers and provide your feedback, if something is not working as planned you can raise new issues.

If you have to create a new issue, go the extra mile and include plenty of information to reproduce the bug, be proactive and genuinely helpful! Help assess other people's tickets, maybe no development is needed and they are just looking for a helping hand.

Who knows, maybe with a bit of time, you'll be in charge of triaging and be the one deciding what are the priorities for the project, isn't that awesome? 😎

In conclusion...

...if you are feeling stuck in your OpenSource journey, I hope this article has thrown some fuel to the fire 🔥 I know it worked for me while I was thinking about it and I'm going to start tomorrow with a different approach and even more excited than today!

Best of luck Developers!

Thanks for reading! And don't forget to follow me if you want to see more content like this!

Hands-On with VSCode & "Dev Containers"

Manuel Castellin — Wed, 30 Sep 2020 20:10:51 +0000

Today I wanted to give Visual Studio Code a try for the first time. Even though I still haven't found my way around it, I discovered an extension that could really be a game-changer for my workflow! 🧨 Thought to share it with you.

The "Remote - Containers" Extension

In simple terms, this extension allows you to use a Docker container as your development environment. 🤯

Everything will be in it: your code, SDKs, dependencies, OS packages.. everything!

I've been looking forward to something like this for a long time, and I have to say, this VSCode extension is very well thought out.

There are several advantages of using "dev containers"...

Compatibility: your code runs in the exact same environment from your development machine all the way to production
Automation & Speed: the creation of a new dev environment is fully automated. You can restore a broken environment (or onboard a new developer) in seconds
PR Review: you can check out the code from a PR in a new, isolated container without messing with your work
It's CLEAN! I have tons of small projects on my laptop that I can't even find anymore. With dev containers I could: checkout a project -> build a dev container -> develop and commit my changes -> destroy it immediately

How I Created My First Dev Container

I'm now going to show you step by step how I created my first "dev container" today.

I grabbed one of the projects I'll be collaborating with this Hacktoberfest. It's a Django application, so this will require our development environment to run with Python3.

First, install the "Remote - Containers" extension from the VSCode marketplace

Second, press F1 to open VSCode menu and search for "Add Development Container Configuration File".

Next, you need to tell VSCode how you would like to create the configuration file. VSCode provides predefined configuration files for the most popular languages so I found one for Python3 very easily 😊

You'll then be asked to choose the Python minor version to use, and if you want to install NodeJS in the container (not sure why 🤔, but I don't care at this point).

VSCode should have created a new folder for you called .devcontainer and generated two files:

a Dockerfile: which is the container definition for your new dev environment
a devcontainer.json file: a configuration file you can use to further customize your development container build process

Customize the `.devcontainer/Dockerfile`

We first look at the Dockerfile and it should look something like this:

# See here for image contents: https://github.com/microsoft/vscode-dev-containers/tree/v0.140.1/containers/python-3/.devcontainer/base.Dockerfile

# [Choice] Python version: 3, 3.8, 3.7, 3.6
ARG VARIANT="3"
FROM mcr.microsoft.com/vscode/devcontainers/python:0-${VARIANT}

# [Option] Install Node.js
ARG INSTALL_NODE="true"
ARG NODE_VERSION="lts/*"
RUN if [ "${INSTALL_NODE}" = "true" ]; then su vscode -c "source /usr/local/share/nvm/nvm.sh && nvm install ${NODE_VERSION} 2>&1"; fi

# [Optional] If your pip requirements rarely change, uncomment this section to add them to the image.
# COPY requirements.txt /tmp/pip-tmp/
# RUN pip3 --disable-pip-version-check --no-cache-dir install -r /tmp/pip-tmp/requirements.txt \
#    && rm -rf /tmp/pip-tmp

# [Optional] Uncomment this section to install additional OS packages.
# RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
#     && apt-get -y install --no-install-recommends <your-package-list-here>

# [Optional] Uncomment this line to install global node packages.
# RUN su vscode -c "source /usr/local/share/nvm/nvm.sh && npm install -g <your-package-here>" 2>&1

What we want to do here, is making sure this container image has everything we need to run our project. In this case, I need to install the required Pip packages listed in the requirements.txt file.

The generated Dockerfile is already suggesting how to do it, I simply have to uncomment a few lines. This is going to be my final Dockerfile:

# [Choice] Python version: 3, 3.8, 3.7, 3.6
ARG VARIANT="3"
FROM mcr.microsoft.com/vscode/devcontainers/python:0-${VARIANT}

# [Option] Install Node.js
ARG INSTALL_NODE="true"
ARG NODE_VERSION="lts/*"
RUN if [ "${INSTALL_NODE}" = "true" ]; then su vscode -c "source /usr/local/share/nvm/nvm.sh && nvm install ${NODE_VERSION} 2>&1"; fi

COPY requirements.txt /tmp/pip-tmp/
RUN pip3 --disable-pip-version-check --no-cache-dir install -r /tmp/pip-tmp/requirements.txt \
   && rm -rf /tmp/pip-tmp

Configure `.devcontainer/devcontainer.json`

The second file generated by VSCode is devcontainer.json. This contains additional information for VSCode to create our development container. Here is how I set it up.

The first section is defining how I want to build my container. I left everything with its default values

        "name": "Python 3",
    "build": {
        "dockerfile": "Dockerfile",
        "context": "..",
        "args": { 
            // Update 'VARIANT' to pick a Python version: 3, 3.6, 3.7, 3.8 
            "VARIANT": "3.8",
            // Options
            "INSTALL_NODE": "false",
            "NODE_VERSION": "lts/*"
        }
    },

Since my Django application is going to run at http://127.0.0.1:8000, I need to forward port 8000 from the host machine into the container, so I uncommented and edited the line below.

    // Use 'forwardPorts' to make a list of ports inside the container available locally.
    "forwardPorts": [8000],

I suggest you take the time to read through the file to find out about all the available options, but here is what mine looks like after the changes:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.140.1/containers/python-3
{
    "name": "Python 3",
    "build": {
        "dockerfile": "Dockerfile",
        "context": "..",
        "args": { 
            // Update 'VARIANT' to pick a Python version: 3, 3.6, 3.7, 3.8 
            "VARIANT": "3.8",
            // Options
            "INSTALL_NODE": "false",
            "NODE_VERSION": "lts/*"
        }
    },

    // Set *default* container specific settings.json values on container create.
    "settings": { 
        "terminal.integrated.shell.linux": "/bin/bash",
        "python.pythonPath": "/usr/local/bin/python",
        "python.linting.enabled": true,
        "python.linting.pylintEnabled": true,
        "python.formatting.autopep8Path": "/usr/local/py-utils/bin/autopep8",
        "python.formatting.blackPath": "/usr/local/py-utils/bin/black",
        "python.formatting.yapfPath": "/usr/local/py-utils/bin/yapf",
        "python.linting.banditPath": "/usr/local/py-utils/bin/bandit",
        "python.linting.flake8Path": "/usr/local/py-utils/bin/flake8",
        "python.linting.mypyPath": "/usr/local/py-utils/bin/mypy",
        "python.linting.pycodestylePath": "/usr/local/py-utils/bin/pycodestyle",
        "python.linting.pydocstylePath": "/usr/local/py-utils/bin/pydocstyle",
        "python.linting.pylintPath": "/usr/local/py-utils/bin/pylint"
    },

    // Add the IDs of extensions you want installed when the container is created.
    "extensions": [
        "ms-python.python"
    ],

    // Use 'forwardPorts' to make a list of ports inside the container available locally.
    "forwardPorts": [8000],

    // Use 'postCreateCommand' to run commands after the container is created.
    // "postCreateCommand": "pip3 install --user -r requirements.txt",

    // Uncomment to connect as a non-root user. See https://aka.ms/vscode-remote/containers/non-root.
    // "remoteUser": "vscode"
}

Opening The Project as a Dev Container

Now that everything is ready, we press F1 again and search for the "Reopen in Container" option.

VSCode will now create a new development container from the Dockerfile and devcontainer.json you created.

Project files in your workspace are now synchronized with the container and VSCode will edit them directly in it.

You'll notice the green strip at the bottom left of the screen indicating VSCode is not attached to our Python 3 dev container.

And to test our brand new environment, let's run the application with python manage.py runserver

Yay! The application is now running on port 8000 and forwarded correctly through localhost!

This was my experience with Dev Containers today...

I'm impressed with this VSCode extension so far and I'm looking forward to learning more about it by using it every day.

Hope this intro will inspire someone else to get started with Dev Containers in VSCode.

Thank you for reading through the end! And don't forget to follow me if you want to see more content like this!

My Top 3 Uses for "Docker Info"

Manuel Castellin — Tue, 29 Sep 2020 07:27:53 +0000

The very first day I started using Docker I used docker info to verify the server was installed correctly on my Mac, and never used it again! 😅

But sometimes it's good to have this simple command in your toolbox to get information quickly. Here are my top 3 uses for docker info:

1. To verify "if" and "which" docker engine is running

It's obvious, I know, but docker info can tell you in the simplest way that the Docker daemon is alive and kicking and that its API is responding correctly.

It's also a quick way to check what Docker version you're running on

❯ docker info | head
Client:
 Debug Mode: false

Server:
 Containers: 29
  Running: 22
  Paused: 0
  Stopped: 7
 Images: 58
 Server Version: 19.03.12

2. System resources limit: CPU & Memory

Are your containers running slowly or not starting at all? Check if your Docker daemon is running with CPU or Memory limits!

❯ docker info | grep -e CPU -e Memory
 CPUs: 2
 Total Memory: 1.945GiB

3. Check engine's proxy settings

If you run Docker in a corporate network, is very common that you need to connect to the internet via a proxy server. If you get connection timeouts it's likely that you don't have the right settings.

❯ docker info | grep -e Proxy
 HTTP Proxy: http://proxy.mycompany.com:3128
 HTTPS Proxy: http://proxy.mycompany.com:3128
 No Proxy: localhost,127.0.0.1

Did you know...

you can print the full list of information in JSON format with this command?

# Using "| jq" to prettify the json output, though not mandatory
❯ docker info -f '{{json .}}' | jq

Do you use `docker info` often?

Tell me how in the comments!

Don't forget to follow me if you want to see more content like this!

What is the coolest automation you created with "Crontab"?

Manuel Castellin — Fri, 25 Sep 2020 07:50:35 +0000

Calling all Linux enthusiasts...

crontab is such a simple tool, but people always find creative ways to create 🔥 awesome 🔥 things with simple tools

Sending mails, running programs, cleaning up files, restore connections, there's a lot you can do by scheduling a shell script

Mine is not that awesome really...

...but it saved me a lot of time over the years. I have a scheduled shell script that cleans up my stale Docker containers and volumes every day. This way my laptop is always tidy and I don't have to hunt disk space hogs 😎 cool enough for me!

What's yours?

ENTRYPOINT vs. CMD: The Dockerfile Dilemma

Manuel Castellin — Thu, 24 Sep 2020 13:25:05 +0000

Since I started using Docker ages ago, I occasionally come across blog posts or videos telling in details how the two are different, but failing to explain how and when to use them

With enough experience...

you quickly realise that each instruction helps in different situations.

The best use for ENTRYPOINT is...

to set the image's main command. Are you running the image as though it was a command? Then ENTRYPOINT is the right choice. In addition to that, you can use CMD to provide additional command line arguments.

For example: you can package the dig command to run DNS queries with this Dockerfile:

FROM ubuntu:18.04

RUN apt-get update &&\
        apt-get install -qqy --no-install-recommends dnsutils

ENTRYPOINT ["dig"]

CMD ["--help"]

Notice that I have provided --help as default command line parameter for the container, this way, if none is provided, we the container displays the help page. (Because you have to love your users, don't you? 🙂)

If you now build and tag your image as dig:latest, you can run DNS queries with ease from any operating system!

# On your Windows or MacOs

❯ docker run dig google.com

; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7619
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     377 IN  A   172.217.23.142

;; Query time: 55 msec
;; SERVER: 192.168.65.1#53(192.168.65.1)
;; WHEN: Thu Sep 24 12:51:14 UTC 2020
;; MSG SIZE  rcvd: 44

AWESOME! 🔥

Forget about ENTRYPOINT...

when your container's users are not already familiar with how the ENTRYPOINT works! It's easy to get fancy by adding magic tricks at container startup, but avoid hiding nasty logic at all costs!

Use CMD for...

everything else! When in doubt, I always use the plain and simple CMD. And if you're not sure what your container should do by default, just give your users a Shell to work with, as simple as that.

CMD ["bash"]

What do you think?

I'm curious to know how you use ENTRYPOINT and CMD in your Dockerfiles!

Thanks for reading! And don't forget to follow me if you want to see more content like this!

DEV Community: Manuel Castellin

SnykCon - Making Sense of Container Security with Snyk CLI and GitHub Actions

But after running a container scan...

A modern approach to security - DevSecOps

Shifting the responsibility towards developers

My experience with Snyk Container scan

Step 0 - creating a Snyk account

Step 1 - start from the development machine

Container image scanning

Stay calm and keep reading

And after applying the suggestion...

Step 2 - CI Integration

Step 3 - Breaking the build

Found it!

Step 4 - Analyzing the report

Wrapping up

Use Docker with Proxy Servers Tutorial

Why should you read this article?

Quick refresher: what is a Proxy server?

How Docker uses proxies

Settings for Docker engine

Setting a Proxy on Docker for Mac/Windows

Using authentication

Setting a Proxy on Linux with Systemd

Running containers with proxy settings

Full Step-By-Step Tutorial

Don't forget to follow me for more content like this!

Hacktoberfest - Ideas for Contributing as a Beginner

My personal dilemma with Hacktoberfest

Creative Ways to Contribute

Documentation & Knowledge Base

READ, READ, then READ MORE!

README.md

Graphic Design

Translate

Educate

Some projects have example repositories!

Organize Notes

Test & Bug Report

In conclusion...

Best of luck Developers!

Hands-On with VSCode & "Dev Containers"

The "Remote - Containers" Extension

There are several advantages of using "dev containers"...

How I Created My First Dev Container

Customize the .devcontainer/Dockerfile

Configure .devcontainer/devcontainer.json

Opening The Project as a Dev Container

This was my experience with Dev Containers today...

My Top 3 Uses for "Docker Info"

1. To verify "if" and "which" docker engine is running

2. System resources limit: CPU & Memory

3. Check engine's proxy settings

Did you know...

Do you use docker info often?

What is the coolest automation you created with "Crontab"?

Calling all Linux enthusiasts...

Mine is not that awesome really...

What's yours?

ENTRYPOINT vs. CMD: The Dockerfile Dilemma

With enough experience...

The best use for ENTRYPOINT is...

Forget about ENTRYPOINT...

Use CMD for...

What do you think?

Customize the `.devcontainer/Dockerfile`

Configure `.devcontainer/devcontainer.json`

Do you use `docker info` often?