DEV Community: Ra

CMD vs ENTRYPOINT: Ini bukan cuma masalah selera, pahami perbedaanya!

Ra — Wed, 05 Mar 2025 07:16:46 +0000

Ketika kita membuat suatu docker image, biasanya kita akan menggunakan command CMD atau ENTRYPOINT untuk menjalankan aplikasi yang kita build. Keduanya terlihat mirip, tetapi apakah keduanya memiliki perbedaan? pada kesempatan kali ini saya akan membahas perbedaan antara command CMD dan ENTRYPOINT dengan cara sederhana. Menggunakan contoh docker image berbasis Alpine dengan command yang familiar dan banyak digunakan oleh kebanyakan orang. Semoga tulisan saya kali ini bisa membantu menjawab pertanyaan kapan harus menggunakan CMD atau ENTRYPOINT, atau mengapa perintah dalam container yang kita buat tidak berjalan seperti yang diharapkan, mari kita mulai. 🚀

Apa itu CMD dan ENTRYPOINT?

CMD pada dasarnya adalah default command dan argument yang selalu dijalankan ketika conainer dijalankan. Contoh Dockerfile:

FROM alpine:3.21.3
CMD ["echo", "Hello World"]

Build dengan menggunakan command docker build -t hello-world:cmd . dan jalankan docker image yang sudah di-build tadi dengan command docker run hello-world:cmd maka outputnya akan seperti ini.

ENTRYPOINT adalah main command yang selalu dikesekusi ketika container dijalankan. Contoh Dockerfile:

FROM alpine:3.21.3
ENTRYPOINT ["echo", "Hello World"]

Build dengan mengunakan command docker build -t hello-world:entrypoint . dan jalankan docker image yang sudah di-build tadi dengan command docker run hello-world:entrypoint maka outputnya akan seperti ini.

Nah sekarang apa yang membedakan antara CMD dan ENTRYPOINT? jika kita lihat ketika menjalankan kedua docker image tersebut menghasilkan output yang sama. Mari kita bahas lebih lanjut.

Perbedaan CMD dan ENTRYPOINT

CMD: jika pengguna memberikan perintah saat menjalankan container, default command tersebut bisa digantikan dengan command yang diberikan ketika menjalankan container.

ENTRYPOINT: jika pengguna memberikan perintah saat menjalankan container, main command tersebut tidak bisa digantikan dengan command yang diberikan ketika menjalankan container.

Bayangkan CMD adalah kendaraan kantor yang sudah disediakan juga supirnya. Pada dasarnya, kendaraan kantor tersebut memiliki destinasi default (command default) seperti dari kantor pusat ke kantor cabang, namun ditengah-tengah jalan bisa kita ubah destinasinya (command default), seperti mampir untuk makan dulu misalnya. Dari analogi ini bisa disimpulkan bahwa command default pada CMD ini bisa di-override saat menjalakan container.

Nah sekarang bayangkan ENTRYPOINT adalah kendaraan umum. Pada dasarnya, kendaraan umum tersebut kan sudah memiliki rutenya tersendiri (main command) seperti dari Daerah A ke Daerah B misalnya dan kita tentu tidak bisa merubah rute (main command) kendaraan umum tersebut dengan sesuka hati. Dari analogi ini, bisa disimpulkan bahwa main command pada ENTRYPOINT ini tidak bisa di-override saat menjalankan container.

Agar bisa dipahami lebih dalam, berikut adalah beberapa contoh dari penggunaan CMD pada docker. Jika kita tetap menggunakan docker image yang kita build sebelumnya untuk CMD dan ingin melakukan override pada default command dengan menjalankan command docker run hello-world:cmd "new message" dengan harapan akan mengeluarkan output berupa pesan “new message” maka outputnya akan seperti ini.

mengapa error ini terjadi? ketika kita menjalankan command docker run hello-world:cmd "new message" maka ini akan diterjemahkan menjadi CMD [”new message”] pada Dockerfile kita. Karena “new message” bukanlah sebuah executable di dalam container atau linux command maka akan muncul error tersebut.

Jika kita ingin mengubah output “Hello World” menjadi “new message”, maka command yang harus dijalankan adalah docker run hello-world:cmd "echo" "new message"

mengapa tidak error? karena ketika command tersebut dijalankan akan diterjemahkan menjadi CMD [”echo”, “new message”].

Sekarang, kita lanjut ke contoh ENTRYPOINT pada docker. Jika kita menjalankan command docker run hello-world:entrypoint "new message" pada docker image ENTRYPOINT yang kita build sebelumnya, maka output-nya akan seperti ini.

mengapa hal ini bisa terjadi? karena main command dari ENTRYPOINT tersebut tidak bisa ter-override dan akan diterjemahkan menjadi ENTRYPOINT [”echo”, “Hello World”, “new message”].

Bagaimana jika kita ingin menjalankan command docker run <docker-image-name:tag> "new message" tetapi output yang diharapkan adalah “new message”? jawabannya kombinasikan keduanya antara CMD dengan ENTRYPOINT. Berikut adalah contoh Dockerfile hasil modufikasi kombinasi keduanya.

FROM alpine:3.21.3
ENTRYPOINT ["echo"]
CMD ["Hello World"]

Build menjadi docker image dengan command docker build -t hello-world:combined . lalu jalankan command docker run hello-world:combined "new message" maka output yang akan dihasilkan akan seperti ini.

output sudah seperti yang diharapkan kan?

Kesimpulan

Gunakan CMD jika ingin default command bisa digantikan dengan command yang diberikan ketika menjalankan container.
Gunakan ENTRYPOINT jika ingin main command tidak bisa digantikan dengan command yang diberikan ketika menjalankan container.
Jika ingin kombinasi antara main command dan default command, maka gunakan keduanya.

From Bloated to Lean: Optimizing Docker Image with Multi-Stage Builds

Ra — Wed, 19 Feb 2025 07:55:16 +0000

Nowadays, containers have become the standard for ensuring portability and consistency across environments. However, without the right approach, container images can become excessively large, slow, and insecure.

One of the biggest culprits behind slow container performance and bloated images is an inefficient build process. When dependencies required only during the build stage are included in the final container image, it results in unnecessary files and tools being carried over. This not only increases security risks but also leads to larger image sizes and slower application performance.

With the multi-stage build technique, applications can be built in separate stages, ensuring that only the necessary artifacts are included in the final image. This approach offers several key benefits in terms of efficiency, image size, and security.

How Multi-Stage Build Works

Multi-stage builds divide the build process into multiple stages within a single Dockerfile, ensuring that only the necessary components are included in the final docker image.

Let me explain this with an analogy. Imagine preparing a dinner for someone special ❤️

Preparation Stage (Build Stage 1)
- You chop vegetables, meat, and other ingredients.
- Tools like a knife, cutting board, and any other stuff are used at this stage.
Cooking Stage (Build Stage 2)
- With all the ingredients ready, you start cooking the dish in a big pan.
- You no longer need the knife and cutting board at this point.
Serving Stage (Final Stage)
- You plate the dish and serve it to your special someone.
- All the cooking tools and raw ingredients are no longer needed.

Without multi-stage builds, it’s like serving your special dish along with the big pan, knife, cutting board, and all the leftover ingredients. Definitely not the best dinner experience! 💔

Implementation in Dockerfile

In the context of the containers, multi-stage builds follow the same concept.

Build Stages (Intermediate Stages) → These stages handle the application build process, such as installing dependencies, compiling code, and preparing the necessary artifacts.
Final Stage → This stage contains only what is needed to run the application, excluding all build dependencies.

Here is a simple “Hello world” program written in Go.

package main

import "fmt"

func main() {
    fmt.Println("hello world")
}

This is an example of building the application without using multi-stage builds.

FROM golang:1.21.4-alpine AS builder
WORKDIR /app
COPY main.go .
RUN go build -o hello-world main.go
CMD ["./hello-world"]

Problem:

The final image includes the entire Go build environment, making it much larger than necessary.
Unused build tools and dependencies remain in the image, increasing security risks.

Without multi-stage builds, the Docker image size reaches 249MB!

Now, let's implement multi-stage builds to build the application.

FROM golang:1.21.4-alpine AS builder
WORKDIR /app
COPY main.go .
RUN go build -o hello-world main.go

FROM alpine:3.21 
WORKDIR /root
COPY --from=builder /app/hello-world .
CMD ["./hello-world"]

Improvements:

The final image only contains the compiled binary (hello-world), reducing the image size significantly.
The Go build environment is no longer included, improving security and efficiency.

As you can see, the docker image is now only 9.64MB, a massive reduction in size!

Summary

Multi-stage builds ensure that only the necessary components are included in the final Docker image, just like serving a meal without the cooking tools and leftover ingredients. This approach offers several key benefits:

Smaller Docker Image Size → Reduces storage needs and speeds up image pull and push operations to the container registry.
Enhanced Security → Eliminates unnecessary tools and dependencies, minimizing attack surfaces.
Faster Build Times → Optimized caching improves efficiency, especially in CI/CD pipelines.

How to Implement HashiCorp Vault SSH Secrets Engine for securing SSH access

Ra — Mon, 12 Aug 2024 10:29:55 +0000

Introduction

Many companies still used traditional username and password auth to connect our remote servers. Using passwords, no matter how complex it is, are vulnurable to various forms of attack, such as brute-force attempts or simply forgotten. In modern infrastructure, SSH is widely used for managing servers remotely. Unlike password-based authentication, SSH uses cryptographic keys to establish a secure connection, which offers a much higher level of security. As more SSH keys are generated and distributed accross different systems and users, it becomes increase and difficult to keep track of them all (key sprawl). There’s also the risk of unauthorized access, granting access to critical systems without detection, especially when former employees retain access they should no longer have. In this article, I’m going to walk through setting up how to implement HashiCorp Vault SSH Secrets Engine for securing SSH access.

Administrator authenticates to vault, enables SSH secrets engine, and generates a public key.
Administrator adds public key from vault to remote servers.
User sends the public key to an administrator for signing.
An administrator creates a certificate using the user’s public key.
The administrator sends the signed certificate to the user.
User using private key and signed certificate to connect to remote servers.

Prerequisite

Install Vault

You can read and follow these docs.

Setup SSH secrets engine

Enable SSH Secrets Engine

# dont forget to export your token by run this command 
export VAULT_TOKEN="<your token>"
vault secrets enable -path=ssh-creds ssh

Or if you are using UI, you can go through secrets engines tab → click enable new engines → click ssh → fill path with ssh-creds.

Configure Vault with CA

Configure Vault with a CA for signing client keys using the /config/ca endpoint. If you do not have an internal CA, Vault can generate a keypair for you.

vault write ssh-creds/config/ca generate_signing_key=true

If you already have a keypair, specify the public and private key parts as part of the payload.

vault write ssh-creds/config/ca \
    private_key="..." \
    public_key="..."

Or if you are using UI, on secrets engines tab, you can click ssh-creds → go to configuration tab → click configure → fill with your public and private key, or you can leave blank.

Get public key and save it

vault read -field=public_key ssh-creds/config/ca > trusted-user-ca-keys.pem

Add the public key to all target host's SSH configuration

Copy trusted-user-ca-keys.pem to /etc/ssh directory in remote server
Add the path where the public key contents are stored to the SSH configuration file as the TrustedUserCAKeys option.
Go to /etc/ssh/sshd_config and then add this.

TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem

This process can be manual or automated using a configuration management tool such as Ansible.

Create roles

Let's say we need to give access to developers, so we need to create a role for developers.
You can run this command.

vault write ssh-creds/roles/developers -<<"EOH"
{
  "algorithm_signer": "rsa-sha2-256",
  "allow_user_certificates": true,
  "allowed_users": "*",
  "allowed_extensions": "permit-pty,permit-port-forwarding",
  "default_extensions": {
    "permit-pty": ""
  },
  "key_type": "ca",
  "default_user": "ubuntu",
  "ttl": "10m0s" 
}
EOH

“algorithm_signer” : "rsa-sha2-256" is a signing algorithm for the key.
"allow_user_certificates": true is allowed to be signed for us as user.
"allowed_users": "*" is list of vault user who are allowed to use this key, "*" means allow all the vault users.
"allowed_extensions": "permit-pty,permit-port-forwarding" for permit-pty is necessary for allowing interactive SSH sessions, where users need to interact directly with the server’s shell. permit-port-forwarding is used to enable secure tunneling of ports, allowing users to access remote services securely through SSH.
"default_extensions" with "permit-pty": "" are included for clarity, consistency, and to ensure that role behavior is explicitly defined.
"key_type": "ca" is the type of key used to log in to hosts. It can be either “OTP” or “ca”. In this example, using ca.
"default_user": "ubuntu" is the default host username when one isn’t specified.
"ttl": "10m0s" is where certificate expiry is set when signing an SSH key, in this example 10 minutes.

If you are using UI, on secrets engines tab, you can click ssh-creds → on roles tab, click create role → fill role name with developers → checklist allow user certificate → fill default username, with ubuntu → fill allowed user with * → select ttl and then fill with 10 minutes → fill allowed extensions with permit-pty,permit-port-forwarding → fill default extensions with "permit-pty": "" → select signing algorithm with rsa-sha2-256.

Sign Public Key

Ask Vault to sign developer's public key. This file usually ends in .pub and the contents begin with ssh-rsa ....

vault write ssh-creds/sign/developers \
    public_key=<developer's public key> > signed-cert.pub

If you are using UI, on secrets engines tab, click ssh-creds → on roles tabs, click developers → paste public key, then save.

SSH into the host machine using the signed key. You must supply both the signed public key from Vault and the corresponding private key as authentication to the SSH call.

ssh -i signed-cert.pub -i <developer's private key> ubuntu@<ip host>

References

https://support.cloudways.com/en/articles/5120579-why-should-you-set-up-ssh-keys
https://developer.hashicorp.com/vault/docs/install
https://developer.hashicorp.com/vault/docs/secrets/ssh/signed-ssh-certificates