How to Install Magento 2.4.6 on Ubuntu 22.04

Magento
Install Diagram

สวัสดีครับ วันนี้ จะมาพูดถึงการ Install Magento 2 (Adobe Commerce) นะครับ
เป็น eCommerce Software ตัวนึง ที่น่าใช้มากๆ มาพร้อมกับ feature ที่ครบครัน ..

รายละเอียดเพิ่มเติม https://business.adobe.com/products/magento/magento-commerce.html

รายละเอียดของ System ประมาณนี้ครับ

- OS: Ubuntu 22.04
- Magento: 2.4.6-p2 (Open Source)
- Apache: 2.4.x
- PHP: 8.1.2
- Composer: 2.2.6
- MySQL: 8.0.34
- Elasticsearch: 7.17.13

มาเริ่มกันเลย ..

Step 1: Update Operating System

# apt update && apt upgrade -y

Step 2: Install Apache Web Server

# apt install apache2

Step 3: Install PHP and PHP extensions

# apt install php php-common libapache2-mod-php php-cli php-fpm php-mysql php-json php-opcache php-gmp php-curl php-intl php-mbstring php-xmlrpc php-gd php-xml php-zip php-soap php-bcmath php-apcu

Modify php.ini file (/etc/php/8.1/cli/php.ini)

memory_limit = 1GB
upload_max_filesize = 256M
zlib.output_compression = On
max_execution_time = 600
max_input_time = 900
date.timezone = Asia/Bangkok

Step 4: Install the MySQL server

# apt install mysql-server
# mysql_secure_installation

Step 5: Create a Magento Database

# mysql -u root -p
mysql> CREATE DATABASE magento;
mysql> CREATE USER 'magento'@'localhost' IDENTIFIED BY 'Str0ngPa$$w0rd';
mysql> GRANT ALL PRIVILEGES ON magento.* TO 'magento'@'localhost';
mysql> FLUSH PRIVILEGES;
mysql> EXIT;

Step 6. Install Elasticsearch

# curl -fsSL https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
# echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list

# apt update && apt install elasticsearch

# systemctl start elasticsearch
# systemctl enable elasticsearch

Verify Elasticsearch

curl -X GET "localhost:9200"

{
"name" : "magento-01",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "-Or5raP6T5uEG3bUG1JYHw",
"version" : {
"number" : "7.17.13",
"build_flavor" : "default",
"build_type" : "deb",
"build_hash" : "2b211dbb8bfdecaf7f5b44d356bdfe54b1050c13",
"build_date" : "2023-08-31T17:33:19.958690787Z",
"build_snapshot" : false,
"lucene_version" : "8.11.1",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}

Step 7: Install Composer

# apt install composer

Step 8: Install Magento

Goto Magento Marketplace https://marketplace.magento.com/

Get Access Keys
My profile > Marketplace > My products > Access Keys

# composer global config http-basic.repo.magento.com Your-Public-Key Your-Private-Key

# composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition=2.4.6-p2 /var/www/magento
# cd /var/www/magento

# bin/magento setup:install \
--base-url=http://your-domain.com \
--db-host=localhost \
--db-name=magento \
--db-user=magento \
--db-password=Str0ngPa$$w0rd \
--admin-firstname=Admin \
--admin-lastname=User \
--admin-email=admin@your-domain.com \
--admin-user=admin \
--admin-password=admin123 \
--language=en_US \
--currency=USD \
--timezone=Asia/Bangkok \
--use-rewrites=1

# chown -R www-data: /var/www/magento

Step 9: Setup Cron jobs

# sudo -u www-data bin/magento cron:install

Step 10: Configure Apache for Magento

Create /etc/apache2/sites-available/magento.conf

<VirtualHost *:80>
ServerAdmin admin@your_domain.com
DocumentRoot /var/www/magento/pub
ServerName your_domain.com
ServerAlias www.your_domain.com

<Directory /var/www/magento>
AllowOverride All
</Directory>

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
# a2ensite magento.conf
# a2enmod rewrite

# systemctl restart apache2

Step 11: Access your Magento installation

Store Front: http://your_domain.com
Admin Dashboard: http://your_domain.com/admin_xxxxxx

Step 12: Diasable 2FA

# bin/magento mod:dis Magento_AdminAdobeImsTwoFactorAuth Magento_TwoFactorAuth
# bin/magento setup:di:compile

Options: Tuning Magento

https://experienceleague.adobe.com/docs/commerce-operations/performance-best-practices/software.html

Filebeat Lightweight shipper for logs from k8s to Elasticsearch

Beat

สวัสดีครับ DevOps 101 ของเรา วันนี้ จะมาพูดถึง Filebeat นะครับ ..

Filebeat คืออะไร?
Filebeat = Lightweight shipper for logs
“Whether you’re collecting from security devices, cloud, containers, hosts, or OT, Filebeat helps you keep the simple things simple by offering a lightweight way to forward and centralize logs and files.”

ถ้าเอาแบบเข้าใจง่ายๆ ก็คือ ตัวกวาด logs จากที่ต่างๆ เข้ามาที่ centralize logs ในที่นี้ ผมจะพูดถึง k8s cluster (EKS) logs ไปเก็บที่ Elasticsearch ละกันนะครับ ..

จริงๆ ยังมี ตัวอื่นๆ อีก นะครับ ที่ทำงานคล้ายๆ Filebeat เช่น Fluentd, Fluentbit

ในเมื่อเราใช้ ELK Stack ใน Ecosystem ของเราแล้ว การที่เราอยาก search logs ต่างๆ ที่เกิดจาก container ของเรา ได้ง่ายสุด ก็คือการ ship logs จาก k8s cluster ของเรา ไปเก็บไว้บน Elasticsearch แล้วทำการ search ผ่าน Kibana ..

วิธีการ Install Filebeat ใน k8s cluster

ทำได้หลายวิธีครับ ในที่นี้ ผมจะใช้วิธีง่ายๆ ผ่าน kubectl ดังต่อไปนี้

1. Create Secret โดยใส่ค่าที่จำเป็น พวกนี้ลงไป

ELASTICSEARCH_HOST = Endpoint ของ Elasticsearch เรา
ELASTICSEARCH_PORT = Port ที่ Elasticsearch เราทำงานอยู่
ELASTICSEARCH_USERNAME = Username ของ Elasticsearch
ELASTICSEARCH_PASSWORD = Password ของ Elasticsearch
ELASTIC_CLOUD_ID = Cloud ID ในกรณีที่เราใช้ผ่าน Cloud Service ของ Elastic.co
ELASTIC_CLOUD_AUTH = Username:Password ของ Elasticsearch

filebeat-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: filebeat
  namespace: kube-system
type: Opaque
data:
  ELASTICSEARCH_HOST: aHR0cDovL2xvY2FsaG9zdA==
  ELASTICSEARCH_PASSWORD: 
  ELASTICSEARCH_PORT: OTIwMA==
  ELASTICSEARCH_USERNAME: 
  ELASTIC_CLOUD_AUTH: 
  ELASTIC_CLOUD_ID: 

จากนั้น สั่ง create secret

kubectl create -f filebeat-secret.yaml

2. Create Deployment และ Resource อื่นๆ

filebeat-kubernetes.yaml

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: filebeat-config
  namespace: kube-system
  labels:
    k8s-app: filebeat
data:
  filebeat.yml: |-
    # To enable hints based autodiscover, remove `filebeat.inputs` configuration and uncomment this:
    filebeat.autodiscover:
      providers:
       - type: kubernetes
         node: ${NODE_NAME}
         hints.enabled: true
         hints.default_config:
           type: container
           paths:
             - /var/log/containers/*${data.kubernetes.container.id}.log

    # Filter by container.name
    # filebeat.autodiscover:
    #   providers:
    #     - type: kubernetes
    #       node: ${NODE_NAME}
    #       templates:
    #         - condition:
    #             contains:
    #               kubernetes.container.name: "container01"
    #           config:
    #             - type: container
    #               paths:
    #                 - "/var/log/containers/*-${data.kubernetes.container.id}.log"
    #         - condition:
    #             contains:
    #               kubernetes.container.name: "container02"
    #           config:
    #             - type: container
    #               paths:
    #                 - "/var/log/containers/*-${data.kubernetes.container.id}.log"

    processors:
      - add_cloud_metadata:
      - add_host_metadata:

    cloud.id: ${ELASTIC_CLOUD_ID}
    cloud.auth: ${ELASTIC_CLOUD_AUTH}

    output.elasticsearch:
      hosts: ['${ELASTICSEARCH_HOST:elasticsearch}:${ELASTICSEARCH_PORT:9200}']
      #index: "%{[fields.my_type]}-%{[agent.version]}-%{+yyyy.MM.dd}" 
      username: ${ELASTICSEARCH_USERNAME}
      password: ${ELASTICSEARCH_PASSWORD}
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat
  namespace: kube-system
  labels:
    k8s-app: filebeat
spec:
  selector:
    matchLabels:
      k8s-app: filebeat
  template:
    metadata:
      labels:
        k8s-app: filebeat
    spec:
      serviceAccountName: filebeat
      terminationGracePeriodSeconds: 30
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet
      containers:
        - name: filebeat
          image: docker.elastic.co/beats/filebeat:8.6.2
          args: ["-c", "/etc/filebeat.yml", "-e"]
          env:
            - name: ELASTICSEARCH_HOST
              valueFrom:
                secretKeyRef:
                  name: filebeat
                  key: ELASTICSEARCH_HOST
            - name: ELASTICSEARCH_PORT
              valueFrom:
                secretKeyRef:
                  name: filebeat
                  key: ELASTICSEARCH_PORT
            - name: ELASTICSEARCH_USERNAME
              valueFrom:
                secretKeyRef:
                  name: filebeat
                  key: ELASTICSEARCH_USERNAME
            - name: ELASTICSEARCH_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: filebeat
                  key: ELASTICSEARCH_PASSWORD
            - name: ELASTIC_CLOUD_ID
              valueFrom:
                secretKeyRef:
                  name: filebeat
                  key: ELASTIC_CLOUD_ID
            - name: ELASTIC_CLOUD_AUTH
              valueFrom:
                secretKeyRef:
                  name: filebeat
                  key: ELASTIC_CLOUD_AUTH
            - name: NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
          securityContext:
            runAsUser: 0
            # If using Red Hat OpenShift uncomment this:
            #privileged: true
          resources:
            limits:
              memory: 200Mi
            requests:
              cpu: 100m
              memory: 100Mi
          volumeMounts:
            - name: config
              mountPath: /etc/filebeat.yml
              readOnly: true
              subPath: filebeat.yml
            - name: data
              mountPath: /usr/share/filebeat/data
            - name: varlibdockercontainers
              mountPath: /var/lib/docker/containers
              readOnly: true
            - name: varlog
              mountPath: /var/log
              readOnly: true
      volumes:
        - name: config
          configMap:
            defaultMode: 0640
            name: filebeat-config
        - name: varlibdockercontainers
          hostPath:
            path: /var/lib/docker/containers
        - name: varlog
          hostPath:
            path: /var/log
        # data folder stores a registry of read status for all files, so we don't send everything again on a Filebeat pod restart
        - name: data
          hostPath:
            # When filebeat runs as non-root user, this directory needs to be writable by group (g+w).
            path: /var/lib/filebeat-data
            type: DirectoryOrCreate
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: filebeat
subjects:
  - kind: ServiceAccount
    name: filebeat
    namespace: kube-system
roleRef:
  kind: ClusterRole
  name: filebeat
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: filebeat
  namespace: kube-system
subjects:
  - kind: ServiceAccount
    name: filebeat
    namespace: kube-system
roleRef:
  kind: Role
  name: filebeat
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: filebeat-kubeadm-config
  namespace: kube-system
subjects:
  - kind: ServiceAccount
    name: filebeat
    namespace: kube-system
roleRef:
  kind: Role
  name: filebeat-kubeadm-config
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: filebeat
  labels:
    k8s-app: filebeat
rules:
  - apiGroups: [""] # "" indicates the core API group
    resources:
      - namespaces
      - pods
      - nodes
    verbs:
      - get
      - watch
      - list
  - apiGroups: ["apps"]
    resources:
      - replicasets
    verbs: ["get", "list", "watch"]
  - apiGroups: ["batch"]
    resources:
      - jobs
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: filebeat
  # should be the namespace where filebeat is running
  namespace: kube-system
  labels:
    k8s-app: filebeat
rules:
  - apiGroups:
      - coordination.k8s.io
    resources:
      - leases
    verbs: ["get", "create", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: filebeat-kubeadm-config
  namespace: kube-system
  labels:
    k8s-app: filebeat
rules:
  - apiGroups: [""]
    resources:
      - configmaps
    resourceNames:
      - kubeadm-config
    verbs: ["get"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: filebeat
  namespace: kube-system
  labels:
    k8s-app: filebeat
---
 

จากนั้น สั่ง create deployment

kubectl create -f filebeat-kubernetes.yaml

3. Search k8s cluster logs ผ่าน Kibana

ถ้า config ทุกอย่างเราถูกต้อง container ทำงานได้ เราก็จะได้ logs ของ k8s cluster เรา ไปเก็บบน Elasticsearch และทำการ search ผ่าน Kibana ได้เลย

Kibana Search

* เราสามารถ filter input ของ Logs ที่จะ ship ไปเก็บ ที่ Elasticsearch ได้

ตัวอย่างอยู่ใน filebeat-kubernetes.yaml ที่ comment ไว้

เป็นอย่างไรกันบ้างครับ ไม่ยากเลยใช่ไหมครับ สำหรับการ ship logs จาก k8s cluster ของเรา ไปเก็บบน Elasticsearch 🙂

Git Repo: https://github.com/pornpasok/k8s-logs-es-filebeat
Ref: https://www.elastic.co/beats/filebeat

Setup Elasticsearch and Kibana OpenID Connect with Azure AD

elastic.co with Azure AD

สวัสดีครับ DevOps 101 ของเรา วันนี้มีเรื่องมาแนะนำ การ setup Single Sign-On (SSO) ของ App เรา .. ด้วย Azure AD โดยที่เรา ไม่จำเป็นต้องมีสิทธิเป็น admin ของ org นั้นๆ .. เป็น user ธรรมดา ก็สามารถ ทำได้
ในที่นี้ จะใช้ในส่วนของ OpenID Connect (OIDC) นะครับ ซึ่งสามารถ ใช้งานทั้งกับ Google, GitHub, AWS Cognito และอื่นๆ ได้ .. แต่ในที่นี้ผมจะใช้เป็น Azure AD นะครับ

จากความต้องการขององค์กร ที่ต้องการให้ พนักงานทุกคน login ด้วย Azure AD หรือถ้าพูดให้เข้าใจง่าย ก็คือใช้ email บริษัท ในทุกๆ App ที่ใช้งาน เนื่องจากเราใช้ Office365 อยู่แล้ว .. จะได้สะดวกในการจัดการ พนักงาน ที่มีการเข้าออก เปลี่ยนแปลงอยู่เสมอ ไม่ต้อง add แบบ local user ..

ในที่นี้ผมจะยกตัวอย่างการ นำ Azure AD (OpenID Connect) มาใช้กับ ELK Stack โดยสามารถใช้ได้ กับ ELK Stack ที่เรา hosted เอง และใช้ได้กับ elastic.co นะครับ ..

วิธีการ Setup OpenID Connect เราสามารถทำตามขั้นตอน ใน docs ของ elastic.co ได้เลยดังนี้
https://www.elastic.co/guide/en/cloud/current/ec-securing-clusters-oidc-op.html#ec-securing-clusters-oidc-op

จากนั้น เราสามาถทำ Role Mappings ได้ใน Kibana อย่างในที่นี้ ผมจะให้ user ที่ login ผ่าน Azure AD (OIDC) ทั้งหมด มี สิทธิแค่ viewer ก็สามารถทำได้ประมาณนี้

User field: realm.name
Type: text
Value: oidc1 (ชื่อ realm ที่เรา config ในหน้า login ของ Kibana)

Kibana Role Mappings

หรือถ้าเรา ต้องการสร้าง Role mapping เฉพาะเจาะจงว่า user (email) คนไหน สามารถทำอะไรเพิ่มเติมได้ บ้าง เราก็สามารถ สร้างเพิ่มได้ ประมาณนี้

User field: username
Type: text
Value: user@email.com (email ของ user ที่เราต้องการ)

Kibana Role Mappings Specific by Email

จะเห็นว่า เราสามารถนำ Azure AD (OpenID Connect) มาใช้กับ Kibana ของเราได้ ทำให้เราสะดวก ในการจัดการ user และการ ทำ Role Mappings ก็ช่วยให้เรา สามารถกำหนด permission ของแต่ละ user ให้แตกต่างกันได้ .. เราไม่ต้องไป add local user บน Elasticsearch และเราสามารถนำ OpenID Connect ไปใช้กับ App อื่นๆ ของเราได้ด้วยเช่นกันครับ .. ไม่ว่าจะเป็น App ที่เราเขียนเอง หรือ OpenSource ต่างๆ ก็รองรับ OpenID Connect กันเป็นส่วนใหญ่ 🙂

ถ้าเพื่อนๆ สงสัยตรงไหน comment กันเข้ามาถามได้นะครับ ไม่ยากครับ ลองไปทำเล่นดู elastic.co เอง ใช้งานได้ฟรี 14 วันครับ หรือถ้าจะ Hosted เองด้วย docker-compose ง่ายๆ ก็ได้ครับ 🙂

ตัวอย่าง: https://github.com/pornpasok/docker-elk

ลองใช้ Argo CD deploy application บน EKS

Argo CD Dashboard
Argo CD Dashboard

DevOps 101 ของเราวันนี้ จะมาทดลองใช้งาน Argo CD กันนะครับ .. ว่ามันดียังไง ทำอะไรได้บ้าง และเหมาะกับใคร? Logo ของ Argo CD ก็น่ารักดีครับ เป็นรูป มนุษย์ต่างดาว หรือ หมึก ก็ไม่รู้ ..

นิยามที่ทาง Argo CD เค้าบอกไว้ ในเว็บเค้าเองก็คือ ..

What Is Argo CD?
“Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes.”

ถ้าสรุปให้เข้าใจได้ง่ายๆ ก็คือ เป็น Tools สำหรับทำ CD (Continuous Delivery) ที่ตรงไปตรงมา
ไม่ซับซ้อน สำหรับ deploy Application บน k8s ด้วยการใช้หลักการของ GitOps

รายละเอียดเพิ่มเติม : https://argo-cd.readthedocs.io/

เท่าที่ลองเล่นดู หลังจากที่เรามี k8s cluster แล้ว (ในที่นี่ผมใช้ EKS) เราก็จะต้อง Install เจ้า Argo CD ใน k8s cluster ของเรา จากนั้น เราก็จะใช้ความสามารถของ Argo CD ได้ ด้วยการผูกกับ Git Repository ที่ใช้ในการ deploy Application ของเรา เท่านี้ก็เป็นอันเรียบร้อยครับ .. เมื่อเรามีการเปลี่ยนแปลง configuration บน git เจ้า Argo CD ก็จะมา sync config ไป deploy บน k8s cluster ให้เรา ..

ดูรายละเอียดเพิ่มเติมที่ YouTube ของ Nana ได้ที่นี่ครับ : https://www.youtube.com/watch?v=MeU5_k9ssrs

สรุปความคิดเห็นส่วนตัว ที่ลองใช้งาน (ยังไม่ได้ใช้จริงๆ จังๆ บน Production)

ข้อดี
– Install ง่ายมาก ไม่เจอปัญหาอะไรเลย ใช้ resource น้อยมาก
– ไม่ต้องวุ่นวาย เรื่องการ Install kubectl เพราะอยู่ใน k8s cluster อยู่แล้ว
– ไม่ต้องวุ่นวาย เรื่องการจัดการ Credentials ในการเข้าถึง k8s cluster
– มี Dashboard ที่แสดงรายละเอียด ของการ deploy Application ได้ละเอียด ครบถ้วน
– Sync manifest จาก Git Repository ได้รวดเร็ว
– หน้าตาดูดี สวยงาม

ข้อเสีย
– Deploy (CD) บน k8s cluster ได้เท่านั้น
– ในส่วนของ CI (Continuous Integration) ยังต้องใช้ 3rd-party อื่นช่วย ไม่ว่าจะเป็น GitHub Action, GitLab CI, Jenkins
– ถ้าดูพวก Metrics ได้ด้วย น่าจะดีเลย แต่คิดว่า คงออกแบบมา ให้ simple ทำงาน CD ได้อย่างดี ก็พอ

[Trick] Deploy Docker Images with Jenkins Pipeline

docker-jenkins-love

DevOps 101 วันนี้ มาขอเล่าเรื่อง trick ง่ายๆ ในการ deploy docker images กันครับ

1. เรื่อง Time Zone โดยปกติแล้ว ถ้าเราไม่กำหนด ตัว container ที่ run จะเป็น UTC นะครับ ในตัวอย่าง ถ้าอยากให้ Time Zone ตรงกับบ้านเรา (UTC +7) เราสามารถ เข้าไป กำหนดได้ง่ายๆ ประมาณนี้ครับ
Dockerfile

FROM python:3.9
ENV TZ="Asia/Bangkok"
RUN date

Build

docker build -t dockertest .

Run

docker run -it dockertest -c "date"

ถ้าเป็น alpine based image จะต้อง install tzdata ก่อน ประมาณนี้ครับ

RUN apk add --no-cache tzdata
ENV TZ Asia/Bangkok

2. เวลา run docker ด้วย tag:latest แล้ว อาจจะมี การ cache บน local ทำให้ ไม่ได้ image ล่าสุด เราสามารถแก้ไขได้โดย ใส่ options –pull=always ตัวอย่างเช่น

docker run --pull=always

3. ถ้าอยาก run Jenkins Pipeliine แบบ trigger ด้วย cron เราสามารถเพิ่ม cron เข้าไปได้ ประมาณนี้


pipeline {
    agent any
    triggers {
        cron('00 20 * * *')
    }

    stages {
        stage('Hello') {
            steps {
                echo 'Hello World'
            }
        }
    }
}

สำหรับการ Set Time Zone ในตัว Jenkins เอง ผมเคยเขียนรายละเอียดไว้แล้วครับ อ่านเพิ่มเติมได้ที่
https://ton.packetlove.com/blog/devops/devops-101-jenkins-set-time-zone.html

อันนี้เป็น trick เล็กๆ น้อยๆ ที่เอามาเล่าสู่กันฟังนะครับ ที่เจอตอน deploy app ที่เป็น docker images ด้วย Jenkins Pipeline 🙂

Lens The Kubernetes IDE + Grafana Dashboard

Lens The Kubernetes IDE

สวัสดีครับ DevOps 101 ของเราวันนี้ นำเสนอ Lens ครับ .. ตอนนี้ ก็ออกมาถึง version 5.x.x กันแล้ว ณ ตอนที่ผมเขียน blog ก็เป็น version 5.1.3 เพื่อนๆ บางท่าน อาจจะเคยใช้งานกันมาบ้างแล้ว .. แต่สำหรับบางท่านที่ยังไม่เคยใช้งาน อาจจะยังสงสัยว่ามันคืออะไรกัน เจ้า Lens .. จากคำอธิบายในเว็บของเค้าคือ ..

“Lens is the only IDE you’ll ever need to take control of your Kubernetes clusters. It’s built on open source and free.”

สรุปสั้นๆ เข้าใจง่ายๆ ก็คือ Lens เป็น IDE ที่ช่วยจัดการ Kubernetes (k8s) cluster ของเรา เป็น Open Source และ Free 🙂
สำหรับท่านที่เคยใช้ kube-proxy ที่เป็น Dashboard ของ k8s เอง .. จะพบว่า มันใช้งานไม่ค่อยสะดวกเท่าไรนัก .. ลองเปลี่ยนมาใช้ Lens ดูครับ จะพบว่าสะดวกกว่ามากๆ ..

สำหรับวิธีการติดตั้ง Lens ก็ไป download ได้เลยครับที่ https://k8slens.dev/ มีทั้งบน Mac OS, Windows และ Linux ครับ .. ตัว Lens เองจะใช้ file config เดียวกับ kubectl ของเราคือจะอยู่ที่ ~/.kube/config ซึ่งถ้าใครใช้งาน kubectl ได้อยู่แล้ว ก็จะไม่มีปัญหา อะไร .. แต่ถ้าเปิด Lens ขึ้นมาแล้ว ยังใช้งานไม่ได้ ก็ให้ไปลองดูที่ ~/.kube/config ว่ามีค่า config ต่างๆ ถูกต้องไหม .. หรือถ้าใครใช้ EKS อยู่ วิธีการง่ายๆ ก็คือ การสั่ง update kube config ครับ ดังตัวอย่าง ..

aws eks update-kubeconfig --name tono-eks \
--region ap-southeast-1 \
--profile tono-admin

สิ่งที่อยากจะนำเสนอเพิ่มเติม สำหรับเจ้า Lens ก็คือ Lens Metrics ซึ่งตรงนี้ จะทำให้เราดู resource ของ k8s cluster เราได้ง่ายขึ้น สะดวกขึ้นครับ .. จริงๆ แล้ว ก็คือการติดตั้ง Prometheus + Kube State Metrics + node exporter เข้าไป เพื่อเก็บ metrics ต่างๆ จาก k8s cluster เราลงบน Prometheus นั่นเองครับ .. มาดูวิธีการ enable ตรงนี้กันครับ ..

1.คลิกขวาที่ icon ของ k8s cluster ของเรา แล้วเลือก Settings

คลิกขวา ที่ icon k8s cluster แล้วเลือก Settings

2.มาที่ Lens Metrics แล้วทำการ Enable PROMETHEUS, KUBE STATE METRICS, NODE EXPORTER จากนั้นกด Apply

Lens Metrics กด Enable ทั้ง 3 อัน

3.กลับมาที่หน้าหลักของ Lens ไปที่ Workloads > Pods ก็จะเห็นว่า pods ต่างๆ ที่เกี่ยวข้องกับ Lens Metrics ของเราเขียวแล้ว

Pods ที่เกี่ยวกับ Lens Metrics เขียวแล้ว

4.กดไปที่ Cluster หรือ Nods ก็จะเห็น Metrics ต่างๆ แสดงผลแล้วครับ

แสดง Metrics ของ k8s cluster ได้แล้ว

ขั้นตอนต่างๆ ก็ง่ายๆ ประมาณนี้ครับ เราก็จะได้ Lens Metrics ที่เป็น Dashboard & Monitoring สำหรับ ดู รายละเอียดต่างๆ ของ k8s cluster ของเรากันแล้วครับ ..

Update!!! (2021-09-25) Grafana Dashboard

วันนี้ มา update การทำ Dashboad & Monitoring ของ k8s cluster ที่จะดูได้ละเอียดกว่านี้ ด้วย Grafana ครับ ..

หลายๆ ท่าน คงอยากมี dashboard (Grafana) เอาไว้ดู metrics ต่างๆ ของ k8s cluster ของเรา ให้คนในทีมได้เอาไว้ดู ในทุกที่ ทุกเวลา .. ซึ่งเราก็สามารถติดตั้งได้ผ่าน Lens เลยครับ โดยมีขั้นตอน เพิ่มเติมดังนี้ ..

1.ไปที่ Apps > Charts แล้ว search “prometheus-operator”

prometheus-operator

2.กด install ใน namespace ที่เราต้องการ ในที่นี้ผม create ns ชื่อ prometheus มาเพิ่มเติม

หรือถ้าอยากลอง install เอง ก็สามารถทำตามขั้นตอน ของ prometheus-operator ได้ตามนี้เลยครับ ..
[Link] https://github.com/prometheus-operator/prometheus-operator

3.ไปที่ Network > Services จะพบ service ที่ชื่อ “prometheus-operator-xxx-grafana”

prometheus-operator-grafana

4.ทำการ login เข้า Grafana โดย default user-password สามารถดูได้ที่ Configuration > Secrets เลือกดู secret “prometheus-operator-xxx-grafana”

prometheus-operator-grafana-password

5.ไปที่ Dashboard จะเห็นว่า มี k8s cluster dashboard ที่จำเป็นมาให้เราเรียบร้อย

Grafana k8s Dashboard & Monitoring

เป็นอย่างไรกันบ้างครับ ไม่ยากเลยใช่ไหมครับ? แต่การที่เราจะ expose Grafana dashboard ของเรา ให้คนอื่น สามารถเข้ามาได้นั้น เราต้องมี ingress มาต่อ กับ service grafana ของเราด้วยนะครับ .. ในครั้งต่อไป ผมจะมาพูดถึงการสร้าง ingress ให้กับ k8s cluster ของเรากันครับ .. 🙂

มาต่อกันครับ ในขั้นตอนการทำให้ Grafana ของเรา สามารถเข้าจากที่ไหน ก็ได้

6. สร้าง Ingress ให้กับ Grafana เรา ให้สามารถเข้าดูจาก public ได้

ในที่นี้ ผมจะ ทำการ create ingress ให้กับ Grafana ของเรากันครับ ด้วย manifest (YAML) ประมาณนี้

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: grafana
  namespace: prometheus
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
    - host: grafana.domain.com
      http:
        paths:
          - backend:
              serviceName: prometheus-operator-xxx-grafana
              servicePort: 80

7. ทำการ Add CNAME record ของ Grafana มาที่ Ingress Endpoint ของเรา

อย่างในที่นี้ ผมใช้บริการ DNS ของ CloudFlare อยู่ ผมก็จะไป Add เพิ่ม ประมาณนี้ครับ

CloudFlare DNS
CloudFlare DNS

เพียงเท่านี้ เราก็จะสามารถเรียกใช้งาน URL ของ Grafana จากที่ไหน ก็ได้แล้วครับ ..

DevOps 101 Jenkins set Time Zone

สวัสดีครับทุกท่าน DevOps 101 ของเราวันนี้ จะมาพูดถึงการ set Time Zone ของ Jenkins กัน .. ผมเชื่อว่าทุกคนคงเคยใช้ Jenkins กันมาแล้ว ก็เลยไม่ได้ลงรายละเอียดตรงส่วนของการใช้งาน Jenkins .. แต่อาจจะเขียนบทความแยก ในส่วนของการ ติดตั้งใช้งาน Jenkins และการสร้าง CI/CD Pipeline บน Jenkins (Jobs) แยกไปอีกบทความนึงนะครับ ..

โดยปกติแล้ว Jenkins จะอ้างอิงเวลา ที่เป็น UTC นะครับ .. เวลาเรา build Jobs เราอาจจะอยากดูเวลาที่เป็นเวลาประเทศไทย (UTC +7) เราก็ต้องนับ +7 เอาเอง ถึงจะเป็นเวลาจริงๆ ณ ตอนนั้น ใน Time Zone ของเรา .. แต่มี trick ง่ายๆ ในการ set ให้ Jenkins แสดงเวลา เป็น Time Zone ของเราครับ แบ่งเป็น 2 วิธีคือ ..

1.Set ให้ทั้งระบบแสดงเวลาให้ default เป็น Time Zone ที่เราต้องการ

เลือก Manage Jenkins > Script Console จากนั้น ใส่ script ดังนี้ครับ แล้วกด Run

System.setProperty('org.apache.commons.jelly.tags.fmt.timeZone', 'Asia/Bangkok')

2.Set การแสดงผล ของแต่ละ user ให้เป็น Time Zone ที่เราต้องการ

เลือก People > เลือก user เราเอง > Configure > User Defined Time Zone จากนั้นให้เลือก Time Zone ที่เราต้องการครับ

เสร็จแล้วจะเห็นว่า เวลาที่แสดง จะเป็นเวลาที่ตรงกับเวลา ที่เป็น Time Zone ของเราครับ ตัวอย่างผมใส่ Asia/Bangkok เวลาที่แสดง ก็จะเป็นเวลา ณ ปัจจุบัน ของประเทศไทยครับ

ก็สั้นๆ ง่ายๆ นะครับ ในการปรับเวลาของ Jenkins ให้ตรงกับ Time Zone ของเรา ทำให้เราดูได้ง่ายขึ้นครับ .. 🙂

ออกแบบ DevOps Architecture CI/CD Pipeline ให้เหมาะกับงาน และองค์กร

DevOps Architecture CI/CD Pipeline

สวัสดีครับ .. DevOps 101 ของเรา วันนี้มีโจทย์ มาอันนึงครับ ให้ออกแบบ Architecture, Tech Stack และ CI/CD Pipeline ของ Application ที่มีคนใช้งานจำนวนมาก app นึง ให้กับองค์กร ขนาดใหญ่ ระดับพนักงาน 200,000 คน ++ ..

จริงๆ ในการออกแบบ ไม่มีอะไรถูกอะไรผิดครับ .. หลักการง่ายๆ ก็คือ “Simply the best” .. ทำให้ deploy ง่ายๆ .. รองรับ load สูงๆ ให้ได้ .. มีระบบ Monitoring ที่ดี .. และเหมาะสม กับงานและองค์กร ..

เนื่องจาก ทางองค์กร มี Single Sign-On อยู่แล้ว ซึ่งสามารถใช้งานผ่าน AWS Cognito ได้ .. เราก็เลยสามารถ ใช้งานได้เลย และเอาไปต่อกับ CI/CD Tools ที่จำเป็นของเราได้ ไม่ว่าจะเป็น GitLab, Jenkins, Nexus Repository และอื่นๆ ในอนาคต ..

ในที่นี้ ตัว Application เราเลือกพัฒนาโดยใช้ Next.js เพราะว่า ต้องรองรับ user ที่เข้าใช้งานหลากหลาย ไม่ว่าจะเป็น บน Desktop และ Mobile .. และทางทีม Developer มีความเชี่ยวชาญในส่วนของ Next.js อยู่แล้ว .. ในส่วนของ CI/CD Tools เราเลือกใช้ Jenkins และทำ CI/CD Pipeline เป็น Jenkinsfile (Declarative Pipeline) แบบง่ายๆ stage ตรงไปตรงมา ใครมาอ่าน ก็เข้าใจ .. เพราะว่าอนาคต เราอยากเอา template นี้ ไป reuse ให้ทีมอื่น ในองค์กร เราได้ใช้ตามด้วย ..

ในส่วนของ Artifactory ที่ใช้เก็บ Docker Images และ binary files ต่างๆ เราเลือกใช้ Nexus Repository เป็น private repository ของเรา .. ส่วน SCM (Source Code Management) อันนี้จริงๆ เราคิดว่า เป็นอะไรก็ได้ ไม่ว่าจะ github, gitlab, ecr, bitbucket .. แต่องค์กรเรามี GitLab อยู่แล้ว ก็เลยใช้ตัวนี้ไปเลย .. ส่วนของ static code scan เราเลือกใช้ SonarQube แต่สิ่งที่เราอยากดูจริงๆ ก็เป็นส่วนของ code coverage มากกว่า ..

ในส่วนของ Server ที่เราจะใช้ในการ deploy ตัว Application ของเราขึ้นไป เราเลือกใช้ Amazon EKS (มันคือ k8s cluster บน AWS) เพราะว่าเราไม่ต้องวุ่นวายในการสร้าง k8s cluster ขึ้นมาใช้งานเอง และตัว cost ของ Amazon EKS ก็ไม่ได้แพงกว่า EC2 ธรรมดา เท่าไรนัก ..

ทำไมถึงเลือกใช้ EKS ไม่ใช้ ECS ?

– ผมเองต้องออกตัวไว้ก่อนครับ ว่าความรู้เกี่ยวกับ ECS ของผม แทบจะเป็น 0 .. แต่จากการได้เข้า training กับ AWS ในส่วนของการใช้งาน ECS + DevOps .. ทำให้ผมพอได้รู้บ้างว่า ตัว ECS ทำงานอย่างไร .. เราสามารถ ทำอะไรกับมันได้บ้าง .. ทำให้ผมตัดสินใจได้ทันที ว่างั้นเราไป EKS เถอะ .. เพราะว่า ในการทำ Application ที่รองรับคนใช้งานจำนวนมากนั้น .. การ scale และการ monitoring metrics ต่างๆ ถือว่าเป็นเรื่องสำคัญมาก ซึ่งผมเองคิดว่า EKS ที่เป็น k8s cluster eco system มัน flexible กว่า .. อาจจะเป็นเหตุผลที่เอนเอียงนิดหน่อย จากการที่ผมคุ้นเคยกับ Container Platform ที่เป็น k8s ด้วย .. (k8s, OpenShift)

ในส่วนของ Dashboard & Monitoring Tools ในที่นี้เราเลือกใช้ APM (Application Performance Monitoring) + ELK Stack ในการ monitoring Application ของเรา ที่เป็น Next.js .. ในส่วนของตัว EKS (k8s Cluster) เราเลือกใช้ Lens + Prometheus เป็น manage และ monitoring metrics ต่างๆ .. แต่ตัว Lens เอง มันคือดูแบบ เครื่องใครเครื่องมัน .. อนาคต ถ้าเราอยากทำเป็น dashboard ให้ทั้งทีม ได้ดูผ่านจอ TV LED ร่วมกัน ก็น่าจะเอา Grafana มาทำ dashboard ในส่วนนี้ .. ส่วนตัว Alert Notification เราใช้เป็น webhook ของ MS Teams เพราะว่าทีมเรา และองค์กรเรา ใช้ MS Teams เป็นหลัก ในการทำงานอยู่แล้ว ..

Tech Stack

– Next.js
– GitLab
– Jenkins
– Nexus Repository
– SonarQube
– nginx
– Docker
– Kubernetes (k8s)
– AWS Cognito
– AWS EKS
– Elasticsearch
– Logstash + APM
– Kibana
– Prometheus
– Lens/Grafana
– Microsoft Teams

Jenkins Pipeline Examples

https://github.com/pornpasok/demo-app-k8s

สำหรับท่านใด ที่สนใจ ในการออกแบบ Architecture, Tech Stack และ CI/CD Pipeline ก็สามารถ มา comment พูดคุย แลกเปลี่ยน ปรึกษากันได้ตรงนี้นะครับ .. อย่างที่ผมเน้นย้ำตลอด ไม่มีแบบไหนผิด แบบไหนถูก .. แต่แบบไหนที่เหมาะกับเรา นั่นแหละ คือดีที่สุด ครับ .. 🙂

DevOps 101 Amazon EKS Upgrade node group (instance type)

Amazon EKS

วันนี้มีเรื่องเร่งด่วน เกี่ยวกับ การ scale out Amazon EKS ก็เลยมาเขียนไว้ กันลืม .. และเป็นการแบ่งปันความรู้ เผื่อเพื่อนๆ ท่านอื่น เจอปัญหาแบบผม และต้องการแก้ไข ให้เร็วที่สุด ..

Elastic Kubernetes Service (Amazon EKS) เป็นอีก service นึงบน AWS ที่เป็นที่นิยมใช้งานกัน ทำให้เราไม่ต้องยุ่งยาก ในการสร้าง kubernetes (k8s) cluster เอง .. โดยเราสามารถ create k8s cluster ของเราขึ้นมาใช้ได้ง่ายๆ ดังนี้ ..

0. Create EKS Cluster

eksctl create cluster \
--name tono-eks \
--version 1.19 \
--region ap-southeast-1 \
--nodegroup-name t3-medium \
--node-type t3.medium \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--ssh-access=true \
--ssh-public-key tono-eks \
--managed --profile tono-admin

0.1 Update kubernetes config

จากนั้น ให้เราทำการ update kubernetes config (~/.kube/config) ด้วยคำสั่ง ..

aws eks --region ap-southeast-1 update-kubeconfig --name tono-eks --profile tono-admin

เพียงเท่านี้ เราก็จะมี k8s cluster ของเราไว้ใช้งานแล้วครับ .. ซึ่งถ้าเรา install เองแบบ k8s hard way จะยุ่งยากมากกกกกก (ก.ไก่ ล้านตัว) +___+

*** เพิ่มเติม –profile tono-admin คือให้ ไปใช้ profile ที่ชื่อ tono-admin ที่เรา config ไว้ใน ~/.aws/credentials

 

แต่เรื่องมันไม่จบเพียงเท่านี้ครับ .. เมื่อเราใช้ไปสักพักนึง EKS Cluster ที่เราสร้างขึ้นมาใช้งาน อาจจะไม่เพียงพอที่จะรองรับ load สูงๆ ได้ .. ที่หน้า console ของ AWS EKS เอง จะมีแค่ให้เลือก เพิ่มจำนวน worker node เท่านั้น ไม่สามารถ แก้ไข instance type เพื่อเพิ่ม spec ได้โดยตรง .. (ทำได้ แต่ต้องไปแก้ Auto Scaling groups ซึ่งยุ่งยาก พอสมควร) แต่เรามีวิธีการใช้ CLI eksctl ในการปรับแต่ง EKS Cluster ของเรา ง่ายๆ ดังนี้ครับ ..

ตัวอย่าง ผมจะเปลี่ยนจากเดิม ที่ใช้ instance type จาก t3.medium เป็น t3.xlarge และ version 1.19 –> 1.20 นะครับ .. ก็จะมี step ดังต่อไปนี้ ..

1. Check EKS node group

eksctl get nodegroups --cluster=tono-eks --profile tono-admin

CLUSTER NODEGROUP STATUS CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID ASG NAME
tono-eks t3-medium ACTIVE 2021-04-01T04:26:02Z 1 4 3 t3.medium AL2_x86_64 eks-cabc45d7-245e-c62e-ca22-bba57282fd0a

จะเห็นว่า ตอนนี้ spec ของ EKS Cluster เรา มีรายละเอียดดังด้านบน

2. Create new node group

eksctl create nodegroup \
--cluster tono-eks \
--version 1.20 \
--name t3-xlarge \
--node-type t3.xlarge \
--nodes 3 \
--nodes-min 1 \
--nodes-max 4 \
--node-ami auto --profile tono-admin

รอจนเสร็จ จะขึ้น all nodegroups have up-to-date configuration

3. Delete old node group

eksctl delete nodegroup --cluster tono-eks --name t3-medium --profile tono-admin

รอจนเสร็จ จะขึ้น deleted 1 nodegroup(s) from cluster “tono-eks”

eksctl_delete_nodegroup

จากนั้นเราก็จะได้ EKS Cluster เป็น worker node ชุดใหม่ ครับ ดังรูป ..

lens_k8s_monitoring_tools

หรือถ้าไม่มี Lens (k8s monitoring tools) ไว้ดู status ของ EKS Cluster แบบผม ก็สามารถใช้ CLI kubectl ได้ครับ ดังนี้

4. Show EKS nodes

kubectl get node

NAME STATUS ROLES AGE VERSION
ip-192-168-31-151.ap-southeast-1.compute.internal Ready 13m v1.20.4-eks-6b7464
ip-192-168-54-97.ap-southeast-1.compute.internal Ready 13m v1.20.4-eks-6b7464
ip-192-168-74-140.ap-southeast-1.compute.internal Ready 13m v1.20.4-eks-6b7464

ปล. สำหรับท่านที่ใช้ k8s แล้วต้องการความสะดวก ในการ monitoring แนะนำ Lens ครับ สะดวกมากกว่าใช้ CLI (kubectl)
Lens: https://k8slens.dev/

เรียบร้อยละครับ เพียงเท่านี้ เราก็สามารถ เพิ่ม spec หรือ scale out EKS Cluster ของเรา ให้รองรับ load สูงๆ ได้แบบง่ายๆ และรวดเร็ว ทันใช้งาน ครับ 🙂

รายละเอียดเพิ่มเติม: https://docs.aws.amazon.com/eks/latest/userguide/migrate-stack.html

DevOps 101 Nexus Repository

สวัสดีครับ วันนี้ผมจะมาพูดถึง tools อีกตัวนึง ที่สำคัญมาก ในการทำ CI/CD นะครับ
นั่นก็คือ Repository ที่เอาไว้เก็บของต่างๆ ของเรา ไม่ว่าจะเป็น docker images, libs, หรือ files binary ต่างๆ ที่นิยมกัน ก็จะมี JFrog Artifactory กับ Nexus วันนี้ ผมจะมาพูดถึงเจ้า Nexus กันนะครับ ..

รายละเอียด เพิ่มเติม https://www.sonatype.com/products/repository-pro

ความสามารถของเจ้า Nexus นั้นมีมากมายมากครับ และมี version ที่เป็น OSS อีกด้วย

ส่วนตัวที่ผมใช้ ก็จะใช้เป็น docker repository กับ docker proxy เพื่อใช้งาน ในองค์กร ทั้งแบบ On-Prem และแบบ Public ครับ หลายๆ ท่านอาจจะคุ้นกับ docker hub จะคล้ายๆ กันเลยครับ ..

อธิบายเพิ่มเติมนะครับ

Docker Repository = ที่เก็บ docker images ของเราครับ มองว่าเป็น docker hub ส่วนตัว ประมาณนั้นครับ ..
Docker Proxy = มองว่าเป็น proxy ที่ไปดึง docker images จากที่อื่นอีกที เช่นไปดึงจาก docker hub อะไรพวกนี้ .. ที่ต้องมี docker proxy นอกเหนือจากช่วย caching docker images แล้ว บางที่ network ภายใน ไม่สามารถ access public โดยตรงได้ ก็เลยต้องใช้เป็น docker repository (docker proxy) ภายในแทนครับ ..

มาดูวิธีการติดตั้งกันครับ ในที่นี่ จะติดตั้งแบบใช้ docker นะครับ (อันนี้ตามสะดวกเลยครับ)

1. Create directory nexus-data

mkdir ~/nexus-data

2. Docker Run

docker run -d -p 8081:8081 -p 5000:5000 -p 5001:5001 --name nexus -v ~/nexus-data:/nexus-data sonatype/nexus3

ที่เรา expose ออกมา 3 port ก็เพื่อเอาไว้ จัดการเรื่องต่างๆ ดังนี้ครับ
– Port 8081 สำหรับหน้า Nexus Dashboard
– Port 5000 สำหรับ docker pull
– Port 5001 สำหรับ docket push

3. จากนั้นเข้า หน้า Nexus Dashboard ด้วย IP:PORT

http://localhost:8081/

4. จะขึ้นหน้า ให้เรา Login จาก password ที่ได้จาก file admin.password

cat ~/nexus-data/admin.password
89e5664b-f748-49e4-a7dc-cdcc3febdd6b

5. เมื่อทำการ update new password เรียบร้อยแล้ว จะเข้ามาที่หน้าแรกของ nexus ให้คลิกที่ รูปเฟือง แล้วเลือก Repositories > Create repositories

Create repositories

6. จะเห็นว่า มีให้เราเลือกเยอะแยะมากมาย ว่าจะ create repositories ประเภทไหนกันบ้าง ..

Select Recipe

ในที่นี้ ผมจะเลือกเป็น docker (hosted) เพื่อเอาไว้เก็บ private docker images ที่เอาไว้ใช้กันเองภายในองค์กร หน่วยงาน แทน public docker repository พวก docker hub ..

7. เลือก Create repository: docker (hosted) ใส่ค่าต่างๆ ประมาณนี้

Name: docker-private
HTTP: 5001 (Port 5001 จะเอาไว้ใช้ docker push)

Create repository: docker (hosted)

8. ต่อมาเลือก Create repository: docker (proxy) ใส่ค่าต่างๆ ประมาณนี้

Name: docker-hub
Remote storage: https://registry-1.docker.io
Docker Index: Use Docker Hub

Create repository: docker (proxy)

9. จากนั้นเลือก Create repository: docker (group) เพื่อรวม docker (hosted) และ docker (proxy) เข้าด้วยกัน ใส่ค่าต่างๆ ประมาณนี้

Name: docker-group
HTTP: 5000 (Port 5000 จะเอาไว้ใช้ docker pull)

Create repository: docker (group)

ตรงด้านล่าง ในส่วนของ Group

Member repositories: ให้คลิกเลือก docker-private และ docker-hub มาอยู่ในส่วนของ Members

Member repositories

*** เพิ่มเติม ***

สำหรับ docker repository ที่ URL ไม่มี SSL (https) เราต้องทำการ set เพิ่มเติม ในส่วนของ Docker Desktop ให้รองรับ insecure-registries โดยไปที่ Preferences > Docker Engine จากนั้น เพิ่มส่วนนี้ลงไป ..

"insecure-registries": ["IP:5000", "IP:5001"],

โดย IP ก็คือ IP ของ Server เรา หรือถ้าเป็น domain ก็ใส่ ชื่อ domain ลงไป

insecure-registries

ในกรณีที่เรา ต้องการ ให้ docker pull ได้แบบ anonymous ไม่ต้องมีการ login
ให้มาติ๊กที่ Allow anonymous docker pull: ในส่วนของ docker-group ครับ

Allow anonymous docker pull:

จากนั้น ให้ไปที่ Realms เลือก Docker Bearer Token Realm เป็น Active

Docker Bearer Token Realm

จากนั้นไปที่ Anonymous Access ติ๊ก Allow anonymous users to access the server ในส่วนของ Realm: เลือก Docker Bearer Token Realm

Anonymous Access

มาถึงวิธีการทดสอบครับ

ให้เราลอง ทดสอบง่ายๆ ประมาณนี้

# Docker Login
docker login http://IP:5000
docker login http://IP:5001
# Docker Pull
docker pull IP:5000/nginx
# Docker Build
docker build -t IP:5000/demo-app .
# Docker Tag
docker tag IP:5000/demo-app IP:5001/demo-app
# Docker Push
docker push IP:5001/demo-app 
# Docker Run
docker run -p 5000:5000 IP:5000/demo-app 

เพียงเท่านี้ เราก็จะได้ docker repository ของเราเองมาใช้แล้วครับ 🙂

แล้วพบกับ การแนะนำ tools ต่างๆ ที่จำเป็น และมีประโยชน์ สำหรับ DevOps (CI/CD) ในตอนต่อไปเร็วๆ นี้ครับ ..