DEV Community: Efkan Isazade

Automating Ubuntu-20.04 live-server template generation with packer vsphere-iso build.

Efkan Isazade — Sun, 10 Jan 2021 16:15:13 +0000

Ubuntu is discontinuing support for the Debian-installer (preseed). Ubuntu Server 20.04 comes with a new automated OS installation method called autoinstall with subiquity server installer. This post shows packer build with new installer.

Update:

This setup is only for Ubuntu-20.04 live-server not legacy.

subiquity

Subiquity is the Ubuntu server’s new automated installer, which was introduced in 18.04. The setup for autoinstallation is given by the cloud-init configuration.
If set, values will be taken from the config file, otherwise default values will be used. There are different ways of delivering cloud-init configuration.
User configuration is usually contained in user-data and cloud configuration in meta-data files.
For more detailed info you can look The AutoInstall documentation provided by Canonical.

Our installer is based on curtin, netplan and cloud-init.

Overview

user-data
packer file
variable file

Lets take a look one by one

#cloud-config
autoinstall:
    version: 1
    early-commands:
        # Stop ssh for packer
        - sudo systemctl stop ssh
    locale: en_US
    keyboard:
        layout: en
        variant: us
    identity:
        hostname: ubuntu-server
        username: ubuntu
        password: '$6$rounds=4096$NYG7e8HxIMgz1$BqP28Ppt0FqXiBQuiE6PxiVBJJJAbm8tJrNz4HC7MEC.7Gv/eOyQIfaLqZ6W6fnMMtxP.BYfHmTBxUFQQs0u91'
    ssh:
        install-server: yes
        allow-pw: yes
    storage:
        layout:
            name: direct
    apt:
        primary:
            - arches: [i386, amd64]
              uri: "http://ro.archive.ubuntu.com/ubuntu/"
    user-data:
      disable_root: false
    late-commands:
      - sed -i -e 's/^#\?PasswordAuthentication.*/PasswordAuthentication yes/g' /target/etc/ssh/sshd_config
      - sed -i -e 's/^#\?PermitRootLogin.*/PermitRootLogin yes/g' /target/etc/ssh/sshd_config
      - echo 'ubuntu ALL=(ALL) NOPASSWD:ALL' > /target/etc/sudoers.d/ubuntu
      - curtin in-target --target=/target -- chmod 440 /etc/sudoers.d/ubuntu
      - curtin in-target --target=/target -- apt-get update
      - curtin in-target --target=/target -- apt-get upgrade --yes

As you see it is .yaml formatted config. We have specifeied all the details (what we need otherwise will use default) in this config. But we need to understand some tricky parts.
Firstly on identity part as you see we have used hashed password. It is default requirement of autoinstaller for security purpose. Actually we need more for deeply secure system but at that moment it is okay. But how we generate this hashed password ?
Actually I used ubuntu as the password for ssh connection and for making it hashed I used below command:

mkpasswd -m SHA-512 --rounds=4096

Now lets move a little bit up and find out early-commands. What it means? Actually when we start packer build, packer try to set ssh connection from the beginning to our machine. So During initialization it could gives us error can break the build. So at the first stage we need to be sure that our ssh connection is stopped.
For understanding all the parts you can look Ubuntu Autoinstall Reference. Fortunately documentation are very simple and useful provided by Canonical.

Now we need to create meta-data file. But we will keep it empty. At last we need to create http directory and put these files into it.

Now we need to define our packer file:

{
  "builders": [
    {
      "CPUs": 2,
      "RAM": 2048,
      "RAM_reserve_all": true,
      "firmware": "bios",
      "boot_command": [
         "<esc><esc><esc>",
         "<enter><wait>",
         "/casper/vmlinuz ",
         "root=/dev/sr0 ",
         "initrd=/casper/initrd ",
         "autoinstall ",
         "ds=nocloud-net;s=http://{{ .HTTPIP }}:{{ .HTTPPort }}/",
         "<enter>"
      ],
      "boot_wait": "2s",
      "convert_to_template": "true",
      "create_snapshot": "false",
      "datacenter": "{{user `vcenter_datacenter`}}",
      "datastore": "{{user `vcenter_datastore`}}",
      "disk_controller_type": "pvscsi",
      "folder": "{{user `vcenter_folder`}}",
      "guest_os_type": "ubuntu64Guest",
      "host": "{{user `vcenter_host`}}",
      "http_directory": "{{user `http_directory`}}",
      "insecure_connection": "true",
      "iso_checksum": "{{user `iso_checksum_type`}}:{{user `iso_checksum`}}",
      "iso_paths": "{{user `iso_paths`}}",
      "name": "Ubuntu-20.04",
      "network_adapters": [
        {
          "network": "{{user `vcenter_network`}}",
          "network_card": "vmxnet3"
        }
      ],
      "notes": "Default SSH User: {{user `ssh_username`}}\nDefault SSH Pass: {{user `ssh_password`}}\nBuilt by Packer @ {{isotime \"2006-01-02 03:04\"}}.",
      "password": "{{user `vcenter_password`}}",
      "shutdown_command": "echo 'ubuntu'|sudo -S shutdown -P now",
      "ssh_password": "{{user `ssh_password`}}",
      "ssh_timeout": "20m",
      "ssh_handshake_attempts": "100000",
      "ssh_username": "{{user `ssh_username`}}",
      "storage": [
        {
          "disk_size": 20480,
          "disk_thin_provisioned": true
        }
      ],
      "type": "vsphere-iso",
      "username": "{{user `vcenter_username`}}",
      "vcenter_server": "{{user `vcenter_server`}}",
      "vm_name": "{{user `vm_name`}}"
    }
  ],
  "provisioners": [
    {
       "type": "shell",
       "execute_command": "echo 'ubuntu' | {{.Vars}} sudo -S -E bash '{{.Path}}'",
       "script": "scripts/setup_ubuntu2004.sh"
     }
   ]
}

I need mention some tricky points now. So as you see I used user keyword on packer file. It is for defining variable. Another most important part is ds=nocloud-net;s=http://{{ .HTTPIP }}:{{ .HTTPPort }}/.
So what it means ? As you remember I created http directory and put config files into it. So we need a web server to serve these files in order packer use them during build process.
When the build is executed, Packer will launch a small HTTP server and replace the {{.HTTPIP}} and {.HTTPPort}} variables with the respective IP and port.
You must also set the http_directory (I already defined in packer file) configuration option to define which directory hosts the files that you want to be served by the HTTP server on your filesystem.
Bu as you wish you can also serve your files with different ways. For example I have uploaded config files to my custom static server and served through this server. I mean instead of http://{{ .HTTPIP }}:{{ .HTTPPort }}/ I used my own server https://ubuntu-cloud-init.vercel.app/ for my enterprise configuration.

At least we need to define variable file. Here is mine:

{
  "vm_name": "Ubuntu-2004-Template",  
  "vcenter_server":"",
  "vcenter_username":"",
  "vcenter_password":"",
  "vcenter_datacenter": "",
  "vcenter_datastore": "",
  "vcenter_host": "",
  "vcenter_folder": "",
  "vcenter_network": "",
  "guest_os_type": "ubuntu64Guest",
  "http_directory": "http",
  "iso_urls": "https://releases.ubuntu.com/focal/ubuntu-20.04.1-live-server-amd64.iso",
  "iso_checksum_type": "sha256",
  "iso_checksum": "443511f6bf12402c12503733059269a2e10dec602916c0a75263e5d990f6bb93",
  "iso_paths": "[Datastore VMS] /packer_cache/ubuntu-20.04.1-live-server-amd64.iso",
  "ssh_username": "ubuntu",
  "ssh_password": "ubuntu"
}

You can use your own custom details for empty vcenter variables.
I have used iso_path variable on packer file. But Also I have added iso_url variable to variable file. So If you dont have ready Ubuntu-20.04 live-server then you can basically change iso_path variable with iso_url in packer file.

This builds a VM Template in vSphere based on Ubuntu 20.04, with a predefined ubuntu/ubuntu user. Although this image is still really helpful, I would like to add another phase to my image.
I plan to use this image with Rancher's vSphere Provisioner which means I need the datasource for vSphere cloud-init. It's available here as a plugin.
So I added a script in provisioners line in packer file:

  "provisioners": [
    {
       "type": "shell",
       "execute_command": "echo 'ubuntu' | {{.Vars}} sudo -S -E bash '{{.Path}}'",
       "script": "scripts/setup_ubuntu2004.sh"
     }
   ]

This sets up the datasource and resets the machine id to reset the state of the machine. You can find both packer file and configs and also script from my github repo.

How to solve VMware ESXI /var partition ramdisk full issue ?

Efkan Isazade — Sun, 10 Jan 2021 16:11:06 +0000

The full /var partition on the ESXI host can trigger host problems. If you keep the /var partition free of space the hosts will be running well in your cluster.

Fixing of the root cause of the runaway log file

When the issue was presented, I wasn't able to connect with any terminal app to hosts so, I had to use the host console. And after a while found that the /var/log/EMU/mili/mili2d.log was continually growing.
In the vsphere syslog found this error:

The ramdisk 'var' is full. As a result, the file `/var/log/EMU/mili/mili2d.log` could not be written.

Then I looked /var/log/EMU/mili/mili2d.log and revealed following errors:

CRITICAL:backend_init:OneConnect Adapter Not Found.
ERROR:rename all the configuration files!
ERROR:MILI_enumerate_elxiscsi:Failed to initialize User Init with status = 19
ERROR:MILI_enumerate_elx_nics:Failed to initialize USer Init with status = 19
ERROR:could not open device node /vmfs/devices/char/vmkdriver/be_esx_nic

What it means ?

Since both servers do not have any Emulex hardware installed, the elxnet drivers are not needed. So I removed them and rebooted hosts. That is it, It solved my problem on the hosts.

esxcli software vib remove --vibname elxnet
esxcli software vib remove --vibname elxiscsi
esxcli software vib remove --vibname elx-esx-libelxima.so

How to enable Gitlab Container Registry with Minio custom S3 Bucket ? Part 2

Efkan Isazade — Sun, 10 Jan 2021 15:58:47 +0000

By default there is a setup may or may not enabled gitlab

In this part we will setup container registry inside self hosted gitlab with Openssl based self genrated ssl. If you wish you can read Part1. Lets get started.
First we need generate SSL cert with Openssl in our gitlab server.

Certificate authority (CA)

openssl req -x509 -nodes -new -sha256 -days 1024 -newkey rsa:2048 -keyout RootCA.key -out RootCA.pem -subj "/C=US/CN=Example-Root-CA"
openssl x509 -outform pem -in RootCA.pem -out RootCA.crt

Example-Root-CA is an example, you can customize the name.

Domain name certificate

Let's say we have two domains gitlab.local and registry.gitlab.local that are hosted on your local machine.

First, create a file domains.ext that lists all your local domains:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
DNS.2 = gitlab.local
DNS.3 = registry.gitlab.local

Now we need to generate localhost.key, localhost.csr, and localhost.crt:

openssl req -new -nodes -newkey rsa:2048 -keyout localhost.key -out localhost.csr -subj "/C=US/ST=YourState/L=YourCity/O=Example-Certificates/CN=localhost.local"
openssl x509 -req -sha256 -days 1024 -in localhost.csr -CA RootCA.pem -CAkey RootCA.key -CAcreateserial -extfile domains.ext -out localhost.crt

The country / state / city / name in the first command can be changed.

Now we can setup registry inside gitlab.

Registry setup

First we need to locate ssl cert and key in /etc/gitlab/ssl

mv ./localhost.crt /etc/gitlab/ssl
mv ./localhost.key /etc/gitlab/ssl

Let’s open up our /etc/gitlab/gitlab.rb file and modify.

...
################################################################################
## Container Registry settings
##! Docs: https://docs.gitlab.com/ce/administration/container_registry.html
################################################################################

registry_external_url 'https://registry.gitlab.local:5050'

##c Settings used by GitLab application
gitlab_rails['registry_enabled'] = true
gitlab_rails['registry_host'] = "registry.gitlab.local"
gitlab_rails['registry_port'] = "5050"
gitlab_rails['registry_path'] = "/var/opt/gitlab/gitlab-rails/shared/registry"

###! **Do not change the following 3 settings unless you know what you are
###!   doing**
# gitlab_rails['registry_api_url'] = "http://localhost:5000"
# gitlab_rails['registry_key_path'] = "/var/opt/gitlab/gitlab-rails/certificate.key"
# gitlab_rails['registry_issuer'] = "omnibus-gitlab-issuer"

### Settings used by Registry application
registry['enable'] = true
registry['health_storagedriver_enabled'] = false
registry_nginx['ssl_certificate'] = "/etc/gitlab/ssl/localhost.crt"
registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/localhost.key"
# registry['username'] = "registry"
# registry['group'] = "registry"
# registry['uid'] = nil
# registry['gid'] = nil
# registry['dir'] = "/var/opt/gitlab/registry"
# registry['registry_http_addr'] = "localhost:5000"
# registry['debug_addr'] = "localhost:5001"
# registry['log_directory'] = "/var/log/gitlab/registry"
# registry['env_directory'] = "/opt/gitlab/etc/registry/env"
# registry['env'] = {
#   'SSL_CERT_DIR' => "/opt/gitlab/embedded/ssl/certs/"
# }
# registry['log_level'] = "info"
# registry['log_formatter'] = "text"
# registry['rootcertbundle'] = "/var/opt/gitlab/registry/certificate.crt"
# registry['health_storagedriver_enabled'] = true
# registry['storage_delete_enabled'] = true
# registry['validation_enabled'] = false
# registry['autoredirect'] = false
# registry['compatibility_schema1_enabled'] = false

### Registry backend storage
###! Docs: https://docs.gitlab.com/ce/administration/container_registry.html#container-registry-storage-driver
registry['storage'] = {
  's3' => {
    'accesskey' => 'minio',
    'secretkey' => 'miniostorage',
    'bucket' => 'gitlab-registry',
    'region' => 'us-east-1',
    'regionendpoint' => 'http://minio.example.com:9000',
    'secure' => false,
    'encrypt' => false,
    'v4Auth' => true
  },
  'redirect' => {
     'disable' => true
  }
}
...

Now I should explain something in this setup.
First off all when we create this setup we have to look if registry storage health check is enabled. We should first make it false if our minio bucket is free. It is a bug and only solution is make storage health check false. After all done you installed image to bucket you can then make health check enable.
Another thing is about registry s3 setup. We should define region as like in aws s3, without it gitlab will give us an exception. You can set any region as you wish and it doesnt matter.
For bucket it is the bucket that you generated in your minio s3 server.
Next thing is about nginx setup. Normally nginx setup for registry is located in the down of the gitlab.rb but for not to copying all the setup I have added it to registry setup.

Now we need to reconfigure gitlab setup. It will not affect anything in your current setup. It will only restart config for gilab.

gitlab-ctl reconfigure

That is it. Now we can login our registry from docker server and push images there.

docker login registry.gitlab.local:5050

If you get output like this:

Output
Login Succeeded

Then it means you are ready to push your images to custom made registry. That is it for now. If you have any problem with this setup please let me know with contact form. Thank you.

How to enable Gitlab Container Registry with Minio custom S3 Bucket ? Part1

Efkan Isazade — Mon, 16 Nov 2020 15:06:21 +0000

By default there is a setup may or may not enabled gitlab registry in Gitlab Omnibus. In this Post you will learn how to enable it and integrate with Minio S3 bucket. In this Part1 we will install and configure Minio server.

Pre-requisites

For this setup we need:

Gitlab Omnibus Server (ce, ee)
Ubuntu 20.04 Server (minimum 4gb ram, 4 cpu, and 250 gb storage)
Docker server to test Gitlab container registry
Openssl or Letsencrypt for secure connection

Minio installation

You can install the Minio server by compiling the source code or via a binary file. To install it from the source, you need to have at least Go 1.12 installed on your system.
First, log in to your server, replacing efe with your username and your_server_ip with your Ubuntu 20.04 server’s IP address:

ssh efe@your_server_ip

Then you have to update package database:

sudo apt update

Next, download the Minio server’s binary file from the official website:

wget https://dl.min.io/server/minio/release/linux-amd64/minio

The output will be similar:

Output
--2020-07-31 15:08:49--  https://dl.min.io/server/minio/release/linux-amd64/minio
Resolving dl.min.io (dl.min.io)... 178.128.69.202
Connecting to dl.min.io (dl.min.io)|178.128.69.202|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 44511616 (42M) [application/octet-stream]
Saving to: ‘minio’

minio               100%[===================>]  42.45M  21.9MB/s    in 1.9s

2020-07-31 15:08:51 (21.9 MB/s) - ‘minio’ saved [44511616/44511616]

When the download is finished, a file named minio will be in your working directory. By the following command to make it executable:

sudo chmod +x minio

Next move the file into the /usr/local/bin directory that Minio’s systemd startup script expects to find it:

sudo mv minio /usr/local/bin

For security reason it is the best practice to avoid Minio server running as root. So we need to create minio user and group.

sudo useradd -r minio-user -s /sbin/nologin

Next, change ownership of the Minio binary to minio-user:

sudo chown minio-user:minio-user /usr/local/bin/minio

Next, we need to create a directory where Minio will store files.

sudo mkdir /usr/local/share/minio

Now we need to give ownership of minio-user to this directory:

sudo chown minio-user:minio-user /usr/local/share/minio

Now we need to create directory inside /etc in order to store Minio configuration file:

sudo mkdir /etc/minio

And then again give ownership of mini-user too:

sudo chown minio-user:minio-user /etc/minio

Now we need to add and modify minio default configuration file:

vim /etc/default/minio

Once the file is open, add in the following lines to set some important environment variables:

MINIO_ACCESS_KEY="minio"
MINIO_VOLUMES="/usr/local/share/minio/"
MINIO_OPTS="-C /etc/minio --address your_server_ip:9000"
MINIO_SECRET_KEY="miniostorage"

You need to change the variables with your own.

Now it is the time to install Minio Systemd Startup Script:

curl -O https://raw.githubusercontent.com/minio/minio-service/master/linux-systemd/minio.service

The output will be similar to the following:

Output

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   835  100   835    0     0   6139      0 --:--:-- --:--:-- --:--:--  6139

In order to audit the contents of minio.service before applying it, open it in a text editor:

vim minio.service

It will show the following:

[Unit]
Description=MinIO
Documentation=https://docs.min.io
Wants=network-online.target
After=network-online.target
AssertFileIsExecutable=/usr/local/bin/minio

[Service]
WorkingDirectory=/usr/local/

User=minio-user
Group=minio-user

EnvironmentFile=/etc/default/minio
ExecStartPre=/bin/bash -c "if [ -z \"${MINIO_VOLUMES}\" ]; then echo \"Variable MINIO_VOLUMES not set in /etc/default/minio\"; exit 1; fi"

ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES

# Let systemd restart this service always
Restart=always

# Specifies the maximum file descriptor number that can be opened by this process
LimitNOFILE=65536

# Disable timeout logic and wait until process is stopped
TimeoutStopSec=infinity
SendSIGKILL=no

[Install]
WantedBy=multi-user.target

# Built for ${project.name}-${project.version} (${project.name})

Then we need to change unit files directories. Systemd requires that unit files be stored in the systemd configuration directory:

sudo mv minio.service /etc/systemd/system

Then, we need to run the following commands to reload all systemd units and enable Minio to start on boot and start Minio:

sudo systemctl daemon-reload
sudo systemctl enable minio
sudo systemctl start minio

I will use default 9000 port on Minio server. So for that we need to enable access configured port through firewall:

sudo ufw allow 9000
sudo ufw enable

You will get the following prompt:

Output
Command may disrupt existing ssh connections. Proceed with operation (y|n)?

Press y and ENTER to confirm this. Output should be like following:

Output
Firewall is active and enabled on system startup

Now our Minio server is ready to accept traffic but in order to make it secure, we need another step to configure Let’s Encrypt(it is free to use) ssl to our Minio server:

First, allow HTTP and HTTPS access through firewall.

sudo ufw allow 80
sudo ufw allow 443

Once all done we can check status:

sudo ufw status verbose

Output should be like that:

Output
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
9000                       ALLOW IN    Anywhere
443                        ALLOW IN    Anywhere
80                         ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)
9000 (v6)                  ALLOW IN    Anywhere (v6)
443 (v6)                   ALLOW IN    Anywhere (v6)
80 (v6)                    ALLOW IN    Anywhere (v6)

Next we will install Certbot. Before generating free wildcard certificates, we need first to make sure certbot is installed and running… To install it, run the commands below:

sudo apt update
sudo apt-get install letsencrypt

Now we can obtain certificate:

sudo certbot certonly --standalone -d minio-server.your_domain

Output should be like that:

Output
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel):

Add your email and press ENTER.

Will then ask you to register with Let’s Encrypt:

Output
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel:

Type A and press ENTER to agree.

Next you will see this output:

Output
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o:

You can answer it yourself both Y or N, then your public and private keys will be generated and saved in the /etc/letsencrypt/live/minio-server.your_domain_name directory.

Next, we need to copy two files (privkey.pem and fullchain.pem) into the certs directory under Minio’s server configuration folder and rename it to private.key:

sudo cp /etc/letsencrypt/live/minio-server.your_domain_name/privkey.pem /etc/minio/certs/private.key

Then do the same for fullchain.pem, naming rename public.crt:

sudo cp /etc/letsencrypt/live/minio-server.your_domain_name/fullchain.pem /etc/minio/certs/public.crt

Now we need to change ownership of private.key and public.crt to mini-user:

sudo chown minio-user:minio-user /etc/minio/certs/private.key
sudo chown minio-user:minio-user /etc/minio/certs/public.crt

Before connect Minio server Web interface, we need to restart it:

sudo systemctl restart minio

At last we can Access the web interface by pointing to https://minio-server.your_domain:9000.

You will see login screen like that:

Now, log in to the main interface by entering credentials.(MINIO_ACCESS_KEY, MINIO_SECRET_KEY)

Then you can create bucket through:

That is it for now... Follow for next Part2. I will share how to connect Gitlab container registry to Minio bucket.

How to enable MongoDB authentication with docker-compose ?

Efkan Isazade — Thu, 21 May 2020 08:23:53 +0000

By default there is no authentication in MongoDB. It means that it comes with empty authentication. So we should create users and roles manually. There are lots of ways to create MongoDB docker-compose with authentication. The most popular one of them is to write a bash script with user and roles then use it in docker-compose and another way is to create an init-mongodb.js file with users and roles and use it in docker-compose. But in this post, I will show you how you could create MongoDB docker-compose and then add users and roles manually. Lets start...

Run MongoDB docker-compose without authentication

First of all we should run MongoDB docker-compose without auth. Using docker-compose up -d we could run it.

Connect MongoDB without auth inside container

For doing that firstly we should run docker exec -it mongodb bash and enter inside the container. Then simply run mongo command to connect to mongodb.

Create user and roles for our MongoDB

Firstly we will create admin user with username root and password root in admin database.

Then we need to create other user. Here I will create a demo user within demo database for our MongoDB:

Now we are ready to run MongoDB with auth.

Enable MongoDB auth in docker-compose

In order to enable auth in MongoDB we will use --auth flag in docker-compose. After that we could use docker-compose up -d command again, to run MongoDB container.

Connect MongoDB with defined authentication

In this step we can connect our db with defined authentication. Firstly again we need to run docker exec -it mongodb bash command in order to enter inside the container. Now we are in so we can connect our db. Here I write 2 command one of them is to connect admin db and another one is to connect demo db.

mongo -u root -p root --authenticationDatabase admin
mongo -u demo -p demo12345 --authenticationDatabase demo