kubectl-like Command Structure

eksdemo ဟာ kubectl လိုပဲ သုံးပါတယ်။ example:

• eksdemo get nodegroup

❯ eksdemo get nodegroup --cluster vtmm-cluster-1
+---------+--------+-----------------------+-------+-----+-----+-----------------+-----------+----------------+
|   Age   | Status |         Name          | Nodes | Min | Max |     Version     |   Type    |  Instance(s)   |
+---------+--------+-----------------------+-------+-----+-----+-----------------+-----------+----------------+
| 5 hours | ACTIVE | eks-master-node       |     1 |   1 |   2 | 1.32.9-20250920 | ON_DEMAND | c7i-flex.large |
| 6 hours | ACTIVE | eks-worker-node-group |     1 |   1 |   2 | 1.32.9-20250920 | ON_DEMAND | c7i-flex.large |
+---------+--------+-----------------------+-------+-----+-----+-----------------+-----------+----------------+

ဒီလို တူညီတဲ့ပုံစံကြောင့် kubectl နဲ့ ရင်းနှီးပြီးသားသူတွေအတွက် eksdemo ကို သုံးရတာ အလွန်လွယ်ကူပါတယ်။ get, create, delete ဆိုတာတွေကို အဓိကသုံးပါတယ်။

kubectl ထက် ဘာတွေပိုထူးခြားလဲ။

eksdemo ရဲ့ အဓိက အားသာချက်ကတော့ Kubernetes object တွေကို AWS resource တွေနဲ့ ချိတ်ဆက်ပြီး ပြသနိုင်စွမ်း ဖြစ်ပါတယ်။

• Viewpoint ကွာခြားမှု:

  • kubectl က Kubernetes API ကိုပဲ အဓိကထားပြီး အလုပ်လုပ်ပါတယ်။ Cluster ထဲက resource တွေကိုပဲ ပြသနိုင်ပါတယ်။

  • eksdemo ကတော့ Kubernetes API ရော၊ AWS API ကိုပါ တစ်ပြိုင်တည်း အသုံးပြုပါတယ်။ ဒါကြောင့် Kubernetes resource တစ်ခုနဲ့ ဆက်စပ်နေတဲ့ AWS resource ကိုပါ တစ်ပါတည်း ဖော်ပြပေးနိုင်ပါတယ်။

      ❯ eksdemo get ec2-instance
      +---------+------------+---------------------+--------------------------------+----------------+------------+
      |   Age   |   State    |         Id          |              Name              |      Type      |    Zone    |
      +---------+------------+---------------------+--------------------------------+----------------+------------+
      | 6 hours | running    | i-06dbfbc142668cb88 |                                | c7i-flex.large | us-east-1a |
      | 6 hours | running    | i-0497519f86b5f5981 |                                | c7i-flex.large | us-east-1c |
      +---------+------------+---------------------+--------------------------------+----------------+------------+
    

      ❯ eksdemo get vpc
      +-----------------------+-----------------------------+----------------+--------------+
      |          Id           |            Name             |  IPv4 CIDR(s)  | IPv6 CIDR(s) |
      +-----------------------+-----------------------------+----------------+--------------+
      | vpc-00bce47ab8ea38db0 | *                           | 172.31.0.0/16  | -            |
      +-----------------------+-----------------------------+----------------+--------------+
      * Indicates default VPC
    

  • Viewing Node:

    • kubectl get nodes လို့ရိုက်ရင် Kubernetes node တွေရဲ့ နာမည်၊ status, role, version စတာတွေကိုပဲ မြင်ရပါမယ်။

    • eksdemo get node လို့ရိုက်ရင်တော့ အဲ့ဒီ Kubernetes node ရဲ့ အောက်မှာ run နေတဲ့ EC2 Instance ID, Instance Type, Subnet ID, AMI (Amazon Machine Image) စတဲ့ AWS အချက်အလက်တွေကိုပါ တစ်ခါတည်း တွဲပြီးပြပေးပါတယ်။

        ❯ eksdemo get node --cluster vtmm-cluster-1
        +---------+--------------------+---------------------+----------------+------------+-----------------------+
        |   Age   |        Name        |     Instance Id     |      Type      |    Zone    |       Nodegroup       |
        +---------+--------------------+---------------------+----------------+------------+-----------------------+
        | 6 hours | ip-172-31-33-128.* | i-0497519f86b5f5981 | c7i-flex.large | us-east-1c | eks-master-node       |
        | 6 hours | ip-172-31-89-30.*  | i-06dbfbc142668cb88 | c7i-flex.large | us-east-1a | eks-worker-node-group |
        +---------+--------------------+---------------------+----------------+------------+-----------------------+
        * Names end with "ec2.internal"
      

command usage အသေးစိတ်အတွက်ကိုလည်း eksdemo ရဲ့ repo လေးကို အောက်မှာထည့်ပေးထားပါတယ်။

အားလုံးပဲအချိန်ပေးပြီးဖတ်ရှုပေးတဲ့အတွက်ကျေးဇူးတင်ပါတယ်။

Initializing your control-plane node

ဒီမှာတော့ ကျွန်တော်တို့ Setup လုပ်မှာက Master Node က တစ်လုံးပဲ အသုံးပြုထားတာဆိုတော့အောက်ပါအတိုင်းပဲ အသုံးပြုပြီး run လို့ရပါတယ်။ တကယ်လို့ ကျွန်တော်တို့က kubeadm init နောက်မှာ ဘာ command တွေထည့်ရမလဲဆိုတာကို မသိဘူးဆိုရင်တော့ kubeadm init —help ဆိုပြီးတော့ စစ်ကြည့်နိုင်ပါတယ်။

kubeadm init --help

ဒါဆိုရင်တော့ control-plane အနေနဲ့ အသုံးပြုမယ့် node ပေါ်မှာ cluster ကို initialize စလုပ်တော့မှာပဲဖြစ်ပါတယ်။

kubeadm init --pod-network-cidr 192.168.0.0/16

Output

[init] Using Kubernetes version: v1.33.4
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action beforehand using 'kubeadm config images pull'
W0820 07:57:40.979712   92014 checks.go:846] detected that the sandbox image "registry.k8s.io/pause:3.8" of the container runtime is inconsistent with that used by kubeadm.It is recommended to use "registry.k8s.io/pause:3.10" as the CRI sandbox image.
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local mdo25-master] and IPs [10.96.0.1 10.230.66.136]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [localhost mdo25-master] and IPs [10.230.66.136 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [localhost mdo25-master] and IPs [10.230.66.136 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "super-admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests"
[kubelet-check] Waiting for a healthy kubelet at http://127.0.0.1:10248/healthz. This can take up to 4m0s
[kubelet-check] The kubelet is healthy after 1.508544566s
[control-plane-check] Waiting for healthy control plane components. This can take up to 4m0s
[control-plane-check] Checking kube-apiserver at https://10.230.66.136:6443/livez
[control-plane-check] Checking kube-controller-manager at https://127.0.0.1:10257/healthz
[control-plane-check] Checking kube-scheduler at https://127.0.0.1:10259/livez
[control-plane-check] kube-controller-manager is healthy after 8.305962353s
[control-plane-check] kube-scheduler is healthy after 12.083902309s
[control-plane-check] kube-apiserver is healthy after 16.004208401s
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node mdo25-master as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node mdo25-master as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule]
[bootstrap-token] Using token: any80c.eqbktrknvek1dklk
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 10.230.66.136:6443 --token any80c.eqbktrknvek1dklk \
        --discovery-token-ca-cert-hash sha256:575ef91069b8af3c00ca7f0fb91f9cf1313aaa070860ac63a3612c197448d4c5

ပြီးသွားရင်တော့ အထက်ပါအတိုင်းမြင်ရမည်ဖြစ်ပြီး Cluster Setup အောင်မြင်သည့်အခါ Your Kubernetes control-plane has initialized successfully! ဆိုပြီးပြနေမည်ဖြစ်သည်။ နောက်ထပ် Kubernetes Cluster ကို manage လုပ်ဖို့အတွက် Kubernetes Config ကို User Directory အောက်က .kube အောက်ထဲသို့ထည့်ပေးရပါမယ်။

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
export KUBECONFIG=/etc/kubernetes/admin.conf

အဲ့ဒါဆိုရင်တော့ Cluster ရဲ့ Node Info ကိုကြည့်ဖို့အတွက် kubectl get nodes command လေးနဲ့ခေါ်ပြီးကြည့်ကြည့်ပါမယ်။

kubectl get nodes
NAME           STATUS     ROLES           AGE     VERSION
mdo25-master   NotReady   control-plane   6m39s   v1.33.3

ဒါဆိုရင်တော့ Cluster Setup လုပ်တယ့် အဆင့်က ပြီးသွားပြီဖြစ်ပါတယ်။ Status မှာ NotReady ဖြစ်နေတာကတော့ Container Network Interface (CNI) Plugin တွေ မသွင်းရသေးသည့်အတွက် NotReady ဖြစ်နေခြင်းဖြစ်ပါသည်။ ဒါကိုတော့ နောက်ထပ် lab တွေကျမှပဲ ပြောပြပေးသွားပါမယ်။ တခြား node တွေ ထပ် join ချင်ရင်တော့ Join ချင်တဲ့ Node မှာ Kubeadm init လုပ်ပြီးတော့ Output မှာပြထားတဲ့ အတိုင်း kubeadm join command ကိုအသုံးပြုပေးရမှာပါပဲဖြစ်ပါတယ်။

kubeadm join 10.230.66.136:6443 --token any80c.eqbktrknvek1dklk \
        --discovery-token-ca-cert-hash sha256:575ef91069b8af3c00ca7f0fb91f9cf1313aaa070860ac63a3612c197448d4c5

Installing and Configuring Prerequisites

Kubernetes Cluster Setup မလုပ်ခင်မှာ လိုအပ်တဲ့ Network Configuration တွေ Cluster အတွက် လိုအပ်သည့် Container Runtime တွေကို အရင်ဆုံးဆုံးအနေနဲ့ Installing လုပ်သွားမှာပဲဖြစ်ပါတယ်။

Enable IPv4 packet forwarding

Network Config အနေနဲ့ကတော့ IPv4 packet forwarding ဆိုသည့် Kernel Option တစ်ခုကို Enable လုပ်ပေးဖို့လိုအပ်ပါတယ်။ IPv4 packet forwarding မရှိခဲ့ရင် network interfaces အမျိုးစုံအကြား network traffic တွေပေးပို့တဲ့အခါမှာ အဆင်မပြေနိုင်တာတွေရှိနိုင်ပါတယ်။ ဥပမာ အနေနဲ့ ပြောရရင် pod-to-pod communication လိုဟာမျိုးတွေပေါ့။ ကျွန်တော်တို့ Cluster ရဲ့ Node A ပေါ်မှာ pod တစ်ခုရှိတယ်ပဲထားပါတော့ဗျာ။ အဲ့ဒီ Node A ရဲ့ pod ကနေ တခြား Node B မှာရှိတယ့် pod ကို packet လေးတွေပို့ချင်တယ်ဆိုပါတော့။ ဒီ packet တွေရောက်ဖို့အတွက်က IPv4 packet forwarding ကို enable လုပ်ထားမှသာ Node A ရဲ့ physical network adapter ကနေတစ်ဆင့် Node B ရဲ့ Network Adapter ကိုဖျက်ပြီးတော့ Node B ရဲ့ pod ကို packet တွေရောက်မှာဖြစ်ပါတယ်။ ဒီ IPv4 packet forwarding kernel option ကို enable လုပ်ထားမှသာ Kubernetes ထဲမှာ အသုံးပြုမယ့် Network CNI Plugin တွေအတွက်လည်းကောင်းမွန်စွာအလုပ်လုပ်မှာ ဖြစ်ပါတယ်။

# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF

# Apply sysctl params without reboot
sudo sysctl --system

net.ipv4.ip_forward ကို 1 ဆိုပြီး setup လုပ်လိုက်တဲ့ ပြန်ခေါ်ကြည့်လို့ output က 1 ပြန်ရတယ်ဆိုရင်တော့ ipv4 packet forwarding enable ဖြစ်နေပါပြီ။

sysctl net.ipv4.ip_forward

Output

ubuntu@mdo25-master:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

နောက်ထပ်အနေနဲ့ cgroups drivers ကို သတ်မှတ်ရမယ်ပေါ့နော်။ ဒါပေမယ့် cgroups drivers ကိုသီးသန့်သွားပြီး လုပ်စရာမလိုတော့ပဲ Kubernetes ရဲ့ v1.22 version ကနေစပြီးတော့ cgroup drivers နေရာမှာ ဘာမှ မသတ်မှတ်ထားခဲ့ရင် kubeadm က default အနေနဲ့ systemd ကိုအသုံးပြုသွားမယ်ဆိုတာမျိုးက ရှိတယ့်အတွက် ထွေထွေထူးထူးတော့ ဘာမှလုပ်စရာမလိုတော့ပါဘူး။ ကျွန်တော်တို့ အသုံးပြုသွားမယ့် Ubuntu Linux Distribution ကလဲ cgroup drivers အနေနဲ့က systemd ကိုပဲသုံးထားတာပဲဖြစ်တယ်။ ဒါကြောင့် cgroup drivers နဲ့ပတ်သက်ပြီးတော့ ဘာမှမသတ်မှတ်တော့ပါဘူး။

Container Runtimes

Container Runtimes အနေနဲ့ကတော့ ဒီ lab မှာ containerd ကိုအသုံးပြုမှာဖြစ်သည့်အတွက် containerd ကို installation လုပ်သွားမှာ ဖြစ်ပါတယ်။

Containerd

Containerd ဆိုတာကတော့ ကျွန်တော်သိတယ့်အတိုင်းပဲ container တွေကို manage လုပ်ဖို့အတွက်သုံးတဲ့ tool တစ်ခုပဲဖြစ်ပါတယ်။ part 1 မှာပြောပြခဲ့အတိုင်း containerd manage လုပ်ဖို့အတွက် ctr ဆိုတယ့် cli tool နဲ့အသုံးပြုပါတယ်။ သူကတော့ docker command တွေနဲ့ အနည်းငယ် different ဖြစ်နေမည်ဖြစ်ပြီး docker က သုံးခဲ့သလိုမျိုးအသုံးပြုချင်ရင်တော့ nerdctl ဆိုတဲ့ cli tool ကိုအသုံးပြုလို့ရပါတယ်။ Kubernetes cluster တစ်ခုထဲမှာ kubelet က container runtime နဲ့ ချိတ်ဆက်ဖို့ Container Runtime Interface (CRI) ကိုသုံးပါတယ်။ အရင်တုန်းကတော့ docker ကို CRI အဖြစ် အသုံးပြုခဲ့တာဖြစ်ပြီးတော့ အခုနောက်ပိုင်းမှာတော့ containerd ကိုသာ CRI အဖြစ် native support လုပ်ပါတယ်။

sudo apt install containerd

containerd ကို install လုပ်တယ့်နေရာမှာ သူရဲ့ dependency ဖြစ်တယ့် runc ကိုပါတစ်ပါတည်း သွင်းသွားမည်ဖြစ်သည်။ containerd ကတော့ high-level runtime ဖြစ်ပြီးတော့ runc ကတော့ low-level runtime အနေနဲ့ ရှိပါတယ်။ containerd က စေခိုင်းသမျှကိုမှ runc အနေနဲ့ container တွေဖန်တီးတဲ့ ကိစ္စရပ်မျိုးတွေကို လုပ်ဆောင်ပေးတာပဲဖြစ်ပါတယ်။

ubuntu@mdo25-master:~$ sudo apt install containerd
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  runc
The following NEW packages will be installed:
  containerd runc
0 upgraded, 2 newly installed, 0 to remove and 62 not upgraded.
Need to get 45.7 MB of archives.
After this operation, 172 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Installation လုပ်ပြီးသွားရင်တော့ containerd service လေးကောင်းမွန်စွာ အလုပ်လုပ်မလုပ်ကို စစ်ချင်သည့် အတွက်

systemctl status containerd

ဆိုပြီး စစ်ကြည့်ပါမယ်။

active (running) ဖြစ်နေပြီ ဖြစ်သည့်အတွက် containerd service က ကောင်းမွန်စွာအလုပ်လုပ်နေပြီလို့ သတ်မှတ်လို့ရပါတယ်။ containerd ကို installation လုပ်ပြီးသွားပြီဆိုတော့ နောက်ထပ်အနေနဲ့ cgroup driver တွေကို configure လုပ်ပေးဖို့လိုအပ်ပါတယ်။

Configuring cgroup driver

cgroup driver ကို configuring လုပ်တဲ့နေရာမှာ ကျွန်တော်တို့ အသုံးပြုထားတဲ့ Ubuntu Linux Distribution က systemd ကိုအသုံးပြုထားတယ့်အတွက် systemd cgroup driver ကို configure လုပ်မှာပဲဖြစ်ပါတယ်။ သူရဲ့ config file လေးကတော့ /etc/containerd/config.toml ဆိုပြီးတော့သွားဆောက်ပေးမှာပဲဖြစ်ပါတယ်။ အရင်ဆုံးအနေနဲ့ /etc အောက်ထဲမှာ containerd ဆိုတယ့် directory တစ်ခုဆောက်ပေးရမှာပဲဖြစ်ပါတယ်။

sudo mkdir /etc/containerd

ပြီးရင်တော့ containerd config ကို create လုပ်ပါမယ်။

containerd config default > /etc/containerd/config.toml

အထက်ပါ command ကိုအသုံးပြုပြီးသွားတဲ့ အခါမှာ /etc/containerd/config.toml ထဲမှာ config တွေ ရောက်နေမည်ဖြစ်ပါသည်။ အဲ့ထဲမှာမှ အောက်ပါပြထားတဲ့အတိုင်း SystemdCgroup နေရာမှာ false ကို true ဆိုပြီး ပြောင်းပေးရမည်ဖြစ်ပါသည်။

ပြီးသွားရင်တော့ config changes ကို containerd ကသိအောင်လို့ containerd service ကို restart ချပေးရပါမယ်။

systemctl restart containerd

ပြီးသွားရင်တော့ containerd service proper ပြန်အလုပ်လုပ်မလုပ်လုပ်ကို systemctl status containerd နဲ့တစ်ချက်စစ်ကြည့်ချင်ရင် စစ်ကြည့်လို့ရပါသည်။ ဘာလို့ပြန်စစ်ခိုင်းတာလဲဆိုတော့ best practice အနေနဲ့လဲ ဖြစ်အောင်တစ်ခုခု changes လုပ်ပြီးတိုင်း restart ချတဲ့အခါ service က ကောင်းမွန်စွာ အလုပ်လုပ် မလုပ်ကို သိစေနိုင်ရန်အတွက်ကြောင့် ဖြစ်ပါတယ်။

Disable Swap

Swap Configuration အနေနဲ့ကတော့ swap ကို disable လုပ်ပေးရမှာပဲဖြစ်ပါတယ်။ node မှာ swap ကိုသာ disable မလုပ်ခဲ့ရင် kubelet service ကို run လိုက်ပြီဆိုတာနဲ့ swap memory ကို detected ဖြစ်နေတဲ့အခါ kubelet service ဟာ ကောင်းကောင်းအလုပ်မလုပ်နိုင်ပဲ fail သွားတာမျိုးတွေ ရှိတတ်ပါတယ်။ အရင်ဆုံးအနေနဲ့ swap က အလုပ်လုပ်နေလားတစ်ချက်အရင်စစ်ကြည့်ပါမယ်။

free -m

Output

root@mdo25-master:~# free -m
               total        used        free      shared  buff/cache   available
Mem:            7936         478        6866           4         843        7457
Swap:              0           0           0

လက်ရှိ ကျွန်တော့်ရဲ့ vm ထဲမှာတော့ swap က မသုံးထားတဲ့အတွက် ထွေထွေထူးထူး ပိတ်စရာတော့မလိုပါဘူး။ တကယ်လို့ Swap ကိုအသုံးပြုထားတယ်ဆိုရင်တော့

swap off -a

အထက်ပါ command ကိုအသုံးပြုပြီး swap ကို disable လုပ်နိုင်သလို /etc/fstab ထဲမှာလည်း swap memory ကို အလုပ်မလုပ်အောင် comment သွားပိတ်ပေးရပါမယ်။

Installing kubeadm, kubelet and kubectl

ဒီအဆင့်မှာတော့ Kubernetes အတွက် လိုအပ်မည့် package ကို စတင် install လုပ်မှာပဲဖြစ်ပါတယ်။

• kubeadm - ကတော့ cluster ကို bootstrap လုပ်ဖို့အတွက်အသုံးပြုရမည့် command ဖြစ်ပါတယ်။

• kubelet - ကတော့ Kubernetes Cluster တစ်ခုလုံးရဲ့ အရေးကြီးဆုံးအစိတ်အပိုင်းတွေထဲက တစ်ခုဖြစ်ပြီး Node တိုင်းမှာ အလုပ်လုပ်တဲ့ service တစ်ခုဖြစ်ပါတယ်။

• kubectl - ကတော့ kubernetes cluster ကို manage လုပ်ဖို့ command line utility tool ပဲဖြစ်ပါတယ်။

ကျွန်တော်တို့က Kubernetes Cluster ကို Ubuntu Linux Distribution ကိုအသုံးပြုမှာဆိုတော့ Debian-based distributions တွေအတွက် Kubernetes Repo တွေကို add ပေးရပါမယ်။ ဒီ Lab မှာတော့ Kubernetes ရဲ့ latest version ဖြစ်တဲ့ v1.33 ကို အသုံးပြုမည်ဖြစ်ပါတယ်။

Update the apt package index and install packages needed to use the Kubernetes apt repository

sudo apt-get update
# apt-transport-https may be a dummy package; if so, you can skip that package
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

Download the public signing key for the Kubernetes package repositories.

# If the directory `/etc/apt/keyrings` does not exist, it should be created before the curl command, read the note below.
# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

Add Kubernetes apt repository

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

Update the apt package index, install kubelet, kubeadm and kubectl, and pin their version:

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

Enable the kubelet service before running kubeadm:

sudo systemctl enable --now kubelet

အဲ့တာဆိုရင်တော့ Kubernetes Cluster Setup လုပ်ဖို့အတွက် လိုအပ်တာတွေအကုန် installation လုပ်ပြီးပြီဖြစ်သည့်အတွက် Part 3 မှာတော့ Cluster Setup လုပ်တဲ့ဟာကို ထပ်မံရေးသားပေးသွားပါမယ်။

အချိန်ပေးပြီးဖတ်ရှုပေးတဲ့အတွက်ကျေးဇူးတင်ပါတယ်။

What is Kubernetes?

Kubernetes ကတော့ Open Source Container Orchestration Platform တစ်ခုဖြစ်ပြီး Google ကနေ Developed လုပ်ခဲ့တာပဲဖြစ်ပါတယ်။ အခုလက်ရှိမှာတော့ Kubernetes ကို Cloud Native Computer Foundation က နေ ကြီးကြပ်နေတာပဲဖြစ်ပါတယ်။ Kubernetes ကတော့ container orchestration tool တစ်ခုဖြစ်တယ့်အတွက် Orchestration Platform အနေနဲ့ပဲ အခြေခံပြီး ထွက်လာတာပေါ့နော်။ Container တွေကို manage လုပ်ဖို့အတွက်ကျတော့ သူ့ထဲမှာမပါဘူး။ ဒါကြောင့် Container Runtime နဲ့ပတ်သက်ပြီးတော့ Container Runtime ဖြစ်တယ့် Docker ပေါ်ကို Relies လုပ်ရတယ်ပေါ့နော်။ နောက်ပိုင်းမှာတော့ ဘာတွေဖြစ်လာလဲဆိုတော့ Kubernetes က Dockershim ကိုဖြုတ်ပြီးတော့ Containerd ကို သူရဲ့ Container Runtime အဖြစ်သုံးလာခဲ့ပါတယ်။ Kubernetes က Support လုပ်တဲ့ Container Engine မှာဆိုရင် Containerd အပြင် CRI-O ဆိုတာလဲရှိသေးတယ်။ Docker Engine ကိုပဲဆက်ပြီးအသုံးပြုချင်တယ်ဆိုရင်လဲ cri-dockerd ဆိုတယ့် tool ကို ကြားခံအသုံးပြုလို့ရပေမယ့် Containerd focus ဖြစ်တယ့်အတွက် တခြားဟာတွေတော့အများကြီးမပြောတော့ပါဘူး။

CRI-O ကိုတော့ Redhat က Develop လုပ်ထားတဲ့ container runtime ဖြစ်ပြီးတော့ သူကကျ containerd လိုမဟုတ်ပဲ low-level ဖြစ်တယ့် runc ကို တန်းပြီးတော့ manage လုပ်နိုင်တယ်။ ပိုပြီးတော့ lightweight ဖြစ်တယ့် runtime အနေနဲ့ ရှိနေတယ်ပေါ့နော်။ Containerd မှာဆိုရင် low-level ဖြစ်တယ့် runc ကို တိုက်ရိုက် manage မလုပ်နိုင်ပဲ containerd-shim ကနေမှတစ်ဆင့် runc ကို manage လုပ်တယ်။ runc ကနေမှ container တွေဖန်တီးတဲ့ ကိစ္စမျိုးတွေကို လုပ်ဆောင်ပေးတာပေါ့နော်။ CRI-O ကတော့ Redhat ရဲ့ Openshift မှာပဲ အဓိကသုံးတာဖြစ်တယ်။ ဒါမယ့် ကျွန်တော်တို့ Kubernetes Community Version မှာလဲ Containerd အစား CRI-O ကိုလဲ သုံးချင်ရင် သုံးလို့ရတယ်ပေါ့နော်။ ဒီမှာတော့ ကျွန်တော်တို့က Containerd ကိုပဲ သုံးသွားမှာဖြစ်တယ့်အတွက် Containerd နဲ့ပတ်သက်တာတွေပဲ ပြောပါမယ်။

ကျွန်တော်တို့ Environment မှာ Containerd ကိုအသုံးပြုထားတယ်ဆိုရင် containerd တွေကို manage လုပ်ဖို့အတွက် ctr ဆိုတယ့် tool ကိုအသုံးပြုပြီး manage လုပ်ရတယ်။ ctr ကတော့ containerd နဲ့ တွဲပြီးအလုပ်လုပ်တဲ့ cli tool ဖြစ်တယ်။ ဒါမယ့် သူက Docker မှာအသုံးပြုခဲ့တယ့် Command တွေနဲ့ နည်းနည်းကွဲတယ်။ Docker မှာလို manage လုပ်တဲ့ပုံစံအတိုင်းကို ctr မှာသွားပြီးတော့ သုံးလို့မရဘူး။ ဒါကြောင့် docker လိုပဲ manage လုပ်ချင်တယ်ဆိုရင်တော့ nerdctl ဆိုတယ့် tool ကိုအသုံးပြုလို့ရတယ်။ Nerdctl က Containerd ကို manage လုပ်တဲ့ docker compactible cli tool တစ်ခုဖြစ်တယ်။ အောက်မှာတော့ Nerdctl ရဲ့ github repo လေးထည့်ပေးထားပါတယ်။ အသေးစိတ်လေ့လာချင်ရင် လေ့လာလို့ရပါတယ်။

Kubernetes Distribution

Kubernetes Distribution တွေကတော့ အများကြီးရှိကြပါတယ်။ Enterprise မှာဆိုရင် Redhat OpenShift, Mirantis Kubernetes Engine, VMware မှာဆိုရင်လဲ Tanzu စသဖြင့်ပေါ့နော်။ Cloud မှာဆိုရင်လဲ သူ့ရဲ့ Cloud Provider ပေါ်မူတည်ပြီး Google မှာဆိုရင် GKE, AWS မှာဆိုရင် EKS, Azure မှာဆိုရင် AKS စသဖြင့်ရှိကြတယ်။ ဒါတွေကတော့ Managed Kubernetes Platform တွေပဲဖြစ်ပါတယ်။ Community Version မှာဆိုရင်တော့ ကျွန်တော်တို့ အခုအသုံးပြုမယ့် Open Source Kubernetes ပေါ့။ သူ့ကိုတော့ တစ်နည်းအားဖြင့် Vanilla Kubernetes လို့လဲခေါ်ကြတယ်။ ကျွန်တော်တို့ရဲ့ Organization မှာ Container နဲ့ပတ်သက်တဲ့ application တွေကို develop လုပ်ပြီးအသုံးပြုတော့မယ်ပေါ့နော်။ အရင်ဆုံးအနေနဲ့ စတင်ပြီးစဥ်းစားရမှာကတော့ ကျွန်တော်တို့ ဘယ် Kubernetes Distribution ကိုသုံးသင့်လဲဆိုတာမျိုးပေါ့။ ထားပါတော့ ကျွန်တော်တို့ Infrastructure မှာ Existing အနေနဲ့ VMware vSphere လိုမျိုးရှိတယ်ဆိုရင် နောက်ထပ် VMware Tanzu ကိုပဲ Add on Subscription ထပ်ဝယ်ပြီးသုံးမလားပေါ့။ ဒါမှမဟုတ် ကျွန်တော်တို့ အသုံးပြုနေတယ့် Product တွေက Redhat နဲ့ပတ်သက်ပြီး Redhat JBoss တို့ တခြား Red Hat 3scale API Management လိုဟာမျိုးတွေ သုံးထားတာမျိုးတွေရှိရင်တော့ ကျွန်တော်တို့အနေနဲ့ စဥ်းစားသင့်တာက Redhat OpenShift Container Platform လိုဟာမျိုးကို စဥ်းစားရမှာပေါ့နော်။ ဒီလိုပဲ ကျွန်တော်တို့ Product တွေက AWS မှာ သုံးထားတယ်ဆိုရင်တော့ EKS လိုမျိုး Elastic Kubernetes Service လိုဟာမျိုးကိုအသုံးပြုသင့်တယ်ပေါ့နော်။ ဒါတွေကတော့ ကိုယ့်ရဲ့ Organization nature ပေါ်မူတည်ပြီးတော့ ရွေးချယ်ရမယ့် ကိစ္စဖြစ်ပါတယ်။ ဒီလောက်ဆိုရင်တော့ Kubernetes Distribution ရွေးချယ်တာနဲ့ ပတ်သက်ပြီးသိမယ်လို့ထင်ပါတယ်။

ကျွန်တော်တို့က Open Source ဖြစ်တယ့် Kubernetes ကိုပဲ အသုံးပြုမှာဆိုတော့ Open Source နဲ့ပတ်သက်တာကိုပဲဆက်ပြီးတော့ သွားကြပါမယ်။ Local Kubernetes Cluster ကို Setup လုပ်ဖို့အတွက် Tool တွေကတော့ မျိုးစုံရှိတယ်ပေါ့နော်။ Minikube ဆိုတာကိုပဲသုံးမလား။ Kind ဆိုတယ့် tool ကိုပဲသုံးမလားပေါ့နော်။ Kind ကတော့ Kubernetes In Docker ပေါ့ Kubernetes Cluster Setup လုပ်တဲ့အခါမှာ Node တွေလိုတယ်။ အဲ့ဒါကိုမှ အဲ့ဒီ Node တွေကို Docker Container အနေနဲ့ ပြန်ပြီး run တဲ့ပုံစံမျိုးအနေနဲ့သုံးပါတယ်။ ကျွန်တော်တို့ အသုံးပြုမှာကတော့ Production အတွက် ready ဖြစ်တယ့် kubeadm ဆိုတယ့် tool ကိုပဲ အသုံးပြုသွားမှာပဲဖြစ်ပါတယ်။ လောလောဆယ်တော့ စာအရမ်းရှည်သွားမှာဆိုးတဲ့အတွက် ဒီလောက်နဲ့ပဲ ခဏရပ်ထားပါမယ်။ Part -2 မှာတော့ Kubeadm နဲ့ Cluster Setup လုပ်တယ့် အကြောင်းကို ထပ်ပြောပြသွားမှာပဲဖြစ်ပါတယ်။

အချိန်ပေးပြီးဖတ်ရှုသည့်အတွက်ကျေးဇူးတင်ပါတယ်။

• Import

• Synchronization

• Export တို့ပဲဖြစ်ပါတယ်။ ဒီ section မှာအဓိကပြောပြသွားမှာကတော့ Export လုပ်နေစဥ်အတွင်းမှာဖြစ်နိုင်တယ့် error များကို ပြောပြသွားမှာပဲဖြစ်ပါတယ်။

Microsoft Entra Connector ကနေ synchronization လုပ်နေစဥ် အတွင်း Identity တွေကို Microsoft Entra Id ကို export လုပ်နေချိန်မှာ error ဖြစ်နိုင်ပါတယ်။ Entra Connector မှာ name format အနေနဲ့ vitaltechmm.onmicrosoft.com သတ်မှတ်ခဲ့ပြီးတော့ Microsoft Entra ID ကို (add, update, delete) စသည့် operation တွေကို export လုပ်နေစဥ်အတွင်းမှာ Microsoft Entra connect (Sync Engine) ရဲ့ Microsoft Entra directory failed ခြင်းကြောင့်ပဲဖြစ်ပါတယ်။ ဖြစ်နိုင်ခြေရှိတဲ့ error တွေကတော့ -

• Data mismatch errors

• ObjectTypeMismatch

• Duplicate attributes

• Data validation failures

• LargeObject တို့ပဲဖြစ်ပါတယ်။

1. Data Mismatch Errors (InvalidSoftMatch)

Microsoft Entra Connect (sync engine) ကနေမှ directory object တွေကို Local AD ကနေ Entra ID ကို add or update စတဲ့ အလုပ်တွေကို instruction စပေးတယ်ပေါ့ဗျာ။ Sync လုပ်လိုက်တဲ့အချိန်မှာ Local AD က sourceAnchor attribute နဲ့ Microsoft Entra ID မှာရှိတဲ့ object ရဲ့ ImmutableId attribute နှစ်ခုကို တိုက်စစ်ပြီး match ဖြစ်သွားတယ်ပေါ့ဗျာ။ အဲ့လိုဖြစ်သွားတာမျိုးကို Hard Match လို့ခေါ်ပါတယ်။ Hard Match ဖြစ်သွားရင်တော့ Entra Connect က existing Entra Id object ကို update လုပ်ပါမယ်။

နောက်ထပ် အနေနဲ့ Microsoft Entra ID ကိုရောက်လာတဲ့ sourceAnchor attribute နဲ့ immutalbleId attribute ကို Hard Match လုပ်တယ်ပေါ့ဗျာ။ ဒါပေမယ့် any object တိုင်းမှာ match ဖြစ်နေတာကို ရှာမတွေ့တဲ့အခါ နောက်ထပ်အနေနဲ့ ProxyAddresses နဲ့ UserPrincipalName attributes တွေ match ဖြစ်မဖြစ်ထပ်ရှာတယ်။ Soft Match ဖြစ်သွားတဲ့အခါမှာလဲ Entra Connect က existing Entra ID object နဲ့ on-premises AD object ကို link လုပ်ဖို့ ကြိုးစားတယ်။ အဲ့ဒါကိုကျတော့ Soft Match လို့ခေါ်ပါတယ်။

InvalidSoftMatch Error ဖြစ်ရသည့် အကြောင်းရင်း ကတော့ Example - johndoe@vitaltechmm.com ဆိုတဲ့ user ကို Entra ID မှာ manually create လုပ်ထားတယ်ပေါ့ဗျာ။ On-Prem AD မှာ johndoe@vitaltechmm.com ဆိုတဲ့ user ကရှိနေတယ်။ အဲ့ဒီ user ကို sync တဲ့အခါမှာ Entra ID မှာရှိတယ့် johndoe user နဲ့ email address တူနေပါလိမ့်မယ်။ အဲ့ဒါကြောင့် Hard Match ဖြစ်မှာမဟုတ်ဘူး။ ဘာလို့လဲဆိုတော့ sourceAnchor နဲ့ immutableId မတူတဲ့အတွက်ကြောင့်ပဲဖြစ်ပါတယ်။ ဒါကြောင့်မလို့ သူက Soft Match လုပ်ဖို့ ထပ်ကြိုးစားပါလိမ့်မယ်။ အဲ့မှာတော့ UserPrincipalName(UPN) or ProxyAddresses တွေက တူနေတယ့်အတွက် soft match ဖြစ်လိမ့်မယ်။ ဒါပေမယ့် sourceAnchor နဲ့ immutableId က မတူတဲ့အတွက် InvalidSoftMatch error ဖြစ်ရခြင်းပဲဖြစ်ပါတယ်။

Entra Connect က တူညီတဲ့ Entra ID object နဲ့ on-premises AD object ကို link မလုပ်နိုင်ဘူး။ ဒါကြောင့် duplicate user ဖြစ်နိုင်တယ် (Entra ID မှာ manually create ထားတဲ့ user နဲ့ sync လုပ်လာတဲ့ user နှစ်ခု ဖြစ်နေပါလိမ့်မယ်)။

How To Fix InvalidSoftMatch Error

Entra ID မှာ manually create ထားတဲ့ user ကို delete လုပ်ပြီး sync ပြန်လုပ်ပါ။ ဒါမှမဟုတ် User ကို delete မလုပ်ချင်ရင်တော့ On-premises AD user ရဲ့ sourceAnchor ကို Entra ID user ရဲ့ immutableId နဲ့တူအောင် လုပ်ပါ။ ဒါမှ Hard Match ဖြစ်ပြီးတော့ InvalidSoftMatch error မဖြစ်တော့ပါဘူး။

အချိန်ပေးပြီး ဖတ်ရှုပေးသည့်အတွက်လည်း ကျေးဇူးတင်ပါတယ်ခင်ဗျ။ ကျန်တဲ့ Error Type ကိုတော့ နောက်ထပ် blog တွေမှာ ထပ်ရေးသွားပေးပါ့မယ်ခင်ဗျ။

Author By: Sc3p73R

Reference: Microsoft Documentation

Overview

CrowdStrike Falcon Sensor ကို ဒီ lab မှာတော့ Helm Chart ကိုအသုံးပြုပြီး install လုပ်မှာဖြစ်ပါတယ်။ Helm Chart ကတော့ kubernetes ပေါ်တွင် falcon sensor install လုပ်ရန် အတွက် လိုအပ်တဲ့ kubernetes resource တွေကို pre-configured လုပ်ပေးထားမည်ဖြစ်ပြီးတော့ helm chart နဲ့ installation လုပ်သည့်အခါတွင် falcon-sensor pod လေးကတော့ Daemonset အနေနဲ့ run သွားမှာပဲဖြစ်ပါတယ်။ ဒီနေရာမှာတော့ Helm တို့ Daemonset အကြောင်းတွေကိုတော့ ပြောသွားတော့မှာမဟုတ်ပါဘူး။

Prerequisites

Prerequisites အနေကတော့ အောက်ပါအတိုင်းပဲဖြစ်ပါသည်။

• you have Helm 3.x or later installed

• your kubernetes cluster nodes are either x86_64 or ARM64, but not both

• your kubernetes vendor supports Helm 3

• you must be a cluster administrator to deploy a Helm chart to the cluster.

• By default, the Helm chart is installed in the default namespace. Best practice is to create a new namespace. See Install the chart archive for info.

• The Falcon sensor for Linux as a DaemonSet should be used as the container image to deploy to a Kubernetes node.

• The Falcon sensor for Linux as a DaemonSet must run as a privileged container so that the sensor can access the kernel.

• The Falcon sensor for Linux as a DaemonSet should be deployed to a Kubernetes environment that grants node access or installation via a Kubernetes DaemonSet.

• The Falcon sensor for Linux as a DaemonSet creates /opt/CrowdStrike on the Kubernetes nodes. Do not delete this folder.

နောက်ထပ်သိရမှာကတော့ CrowdStrike က Region ပေါ်အခြေခံပြီးတော့ သူ့ရဲ့ Cloud Domain URL တွေကလည်းမတူညီပါဘူး။ ဒါတွေကိုသိအောင်လို့ ကျွန်တော်အောက်မှာ List လုပ်ပေးထားပါတယ်။

Cloud domains for US-1

ts01-b.cloudsink.net
lfodown01-b.cloudsink.net
lfoup01-b.cloudsink.net
https://falcon.crowdstrike.com
https://assets.falcon.crowdstrike.com
https://assets-public.falcon.crowdstrike.com
https://api.crowdstrike.com
https://firehose.crowdstrike.com

CrowdStrike Cloud US-2 domains

ts01-gyr-maverick.cloudsink.net
lfodown01-gyr-maverick.cloudsink.net
lfoup01-gyr-maverick.cloudsink.net
https://falcon.us-2.crowdstrike.com
https://assets.falcon.us-2.crowdstrike.com
https://assets-public.falcon.us-2.crowdstrike.com
https://api.us-2.crowdstrike.com
https://firehose.us-2.crowdstrike.com

CrowdStrike Cloud EU-1 domains

ts01-lanner-lion.cloudsink.net
lfodown01-lanner-lion.cloudsink.net
lfoup01-lanner-lion.cloudsink.net
https://falcon.eu-1.crowdstrike.com
https://assets.falcon.eu-1.crowdstrike.com
https://assets-public.falcon.eu-1.crowdstrike.com
https://api.eu-1.crowdstrike.com
https://firehose.eu-1.crowdstrike.com

CrowdStrike Cloud US-GOV-1 domains

ts01-laggar-gcw.cloudsink.net
sensorproxy-laggar-g-524628337.us-gov-west-1.elb.amazonaws.com
lfodown01-laggar-gcw.cloudsink.net
ELB-Laggar-P-LFO-DOWNLOAD-1265997121.us-gov-west-1.elb.amazonaws.com
https://falcon.laggar.gcw.crowdstrike.com
laggar-falconui01-g-245478519.us-gov-west-1.elb.amazonaws.com
https://api.laggar.gcw.crowdstrike.com
https://firehose.laggar.gcw.crowdstrike.com
falconhose-laggar01-g-720386815.us-gov-west-1.elb.amazonaws.com

CrowdStrike Cloud US-GOV-2 domains

ts01-us-gov-2.cloudsink.crowdstrike.mil
lfodown01-us-gov-2.cloudsink.crowdstrike.mil
https://falcon.us-gov-2.crowdstrike.mil
https://api.us-gov-2.crowdstrike.mil
https://firehose.us-gov-2.crowdstrike.mil

တို့ပဲဖြစ်ပါတယ်။

Multi-architecture sensor image

CrowdStrike ရဲ့ Falcon Sensor ကတော့ Linux image version 7.15 နဲ့ နောက်ပိုင်းတွေမှာတော့ Multi-Architecture နဲ့လုပ်ထားတဲ့ image တွေဖြစ်လာပါတယ်။ ဆိုလိုရင်းကတော့ Falcon Sensor ရဲ့ ဒီ Image တစ်ခုတည်းကိုပဲ x86_64 and aarch64 nodes တွေပေါ်မှာ တစ်ပြိုင်နက်အသုံးပြုလို့ရလာတာပဲဖြစ်ပါတယ်။ နမူနာအနေနဲ့ အောက်မှာ Linux image version 7.15 နဲ့ 7.14 ကို ယှဥ်ပြပေးထားပါတယ်။

The Falcon sensor for Linux Image 7.15 and later

Syntax: falcon-sensor:<release_number>-<build_number>-<baseImage_number>.falcon-linux.Release.<cloud-env>

Example: falcon-sensor:7.15.0-15501-1.falcon-linux.Release.US-1

The Falcon sensor for Linux Image 7.14 and earlier

Syntax: falcon-sensor:<release_number>-<build_number>-<baseImage_number>.falcon-linux.<architecture>.Release.<cloud-env>

Example: falcon-sensor:7.14.0-14401-1.falcon-linux.x86_64.Release.US-1

Example အတိုင်း 7.14 နဲ့ အစောပိုင်း version တွေဆိုရင် falcon sensor image တွေကို x86_64 Architecture အတွက်ဆို release သပ်သပ် aarch64 အတွက်ဆို release သပ်သပ်ထုတ်ခဲ့ပါတယ်။ 7.15 version ကနေစပြီးတော့ falcon sensor image တွေကို သပ်သပ်မထုတ်တော့ပဲ multi-architecture အဆင်ပြေအောင် ထုတ်ခဲ့တာပဲဖြစ်ပါတယ်။

Deploy with Helm

Step 1: Create an API client ID and secret

အရင်ဆုံး အနေနဲ့ CrowdStrike falcon sensor ရဲ့ image ကို pull လို့ရဖို့အတွက် ကျွန်တော်တို့ရဲ့ CrowdStrike Portal ထဲကနေ API client id နဲ့ secret ကို create လုပ်ပေးရမှာပဲဖြစ်ပါတယ်။ ဘယ်မှာသွား create ရမလဲဆိုတော့ https://falcon.crowdstrike.com ထဲကို ဝင်ပြီးတော့ Support and resources > Resources and tools > API clients and keys ထဲမှာ အသစ် create လုပ်ပေးရပါမယ်။

ရလာတဲ့ api clients and keys ကို မှတ်ထားပြီးတော့ ကျွန်တော်တို့ရဲ့ စက်ထဲမှာပဲ environment variables ကြေညာပေးရမှာဖြစ်ပါတယ်။

export FALCON_CLIENT_ID=<YOUR_FALCON_CLIENT_ID>

export FALCON_CLIENT_SECRET=<YOUR_FALCON_CLIENT_SECRET>

Step 2: Get your CID with checksum

နောက်တစ်ဆင့်အနေနဲ့ Falcon console ထဲကနေပဲ Customer ID checksum ကိုသွားယူပြီး variable အဖြစ်ကြေညာပေးရမှာပဲဖြစ်ပါတယ်။

export FALCON_CID=<YOUR_CID_WITH_CHECKSUM>

Pull the image from the CrowdStrike registry

နောက်ထပ်အနေနဲ့ CrowdStrike registry က falcon-sensor image ကို pullလုပ်ရမှာပဲဖြစ်ပါတယ်။

curl -sSL -o falcon-container-sensor-pull.sh "https://raw.githubusercontent.com/CrowdStrike/falcon-scripts/main/bash/containers/falcon-container-sensor-pull/falcon-container-sensor-pull.sh"
chmod +x falcon-container-sensor-pull.sh

ပြီးသွားရင်တော့ ကျွန်တော်တို့စက်ထဲရောက်လာသည့် falcon-container-sensor-pull.sh script လေးကို အောက်ပါအတိုင်း run ပေးရပါမယ်။

./falcon-container-sensor-pull.sh \
  -u $FALCON_CLIENT_ID \
  -s $FALCON_CLIENT_SECRET \
  --list-tags \
  -t falcon-sensor

အဲ့တာဆိုရင်တော့ OUTPUT အနေနဲ့

{
  "name" : "falcon-sensor",
  "tags" : [ "6.35.0-13206.falcon-linux.x86_64.Release.US-2", 
… 
"7.15.0-15501-1.falcon-linux.Release.US-2" ]
}

အခုလိုမျိုးပြမှာပဲဖြစ်ပါတယ်။

နောက်ထပ်အနေနဲ့ CrowdStrike registry နဲ့ image tag တို့ကို variable အနေနဲ့ သတ်မှတ်ပေးရမှာဖြစ်ပါတယ်။

Set variables for the CrowdStrike registry and the image tag:

export FALCON_IMAGE_REPO=registry.crowdstrike.com/falcon-sensor/<cloud_tag>/release/falcon-sensor
export FALCON_IMAGE_TAG=7.15.0-15501-1.falcon-linux.Release.<cloud_region>

Note: <cloud_tag> မှာတော့ မိမိရဲ့ crowdstrike cloud domain ကိုထည့်ပေးရမည်ဖြစ်ပါသည်။ region အလိုက် <cloud_tag> တွေက ကွဲမှာဖြစ်ပြီးတော့ us-1, us-2, eu-1, govcloud စသဖြင့် မိမိ region အလိုက်ထည့်ပေးရမှာပဲ ဖြစ်ပါတယ်။ <cloud_region> လဲထိုနည်းတူစွာပါပဲ <cloud_region> မှာ သူရဲ့သက်ဆိုင်ရာ region - US-1, US-2, EU-1, GOV-1 တို့ကို ထည့်ပေးရပါမယ်။ ကျွန်တော်ကတော့ ပုံပါအတိုင်း US-2 region ဖြစ်တယ့်အတွက် <cloud_tag> နေရာမှာ us-2 ကို ထည့်ပေးရမည်ဖြစ်ပြီး <cloud_region> နေရာမှာ US-2 ဆိုပြီး change ပေးရမှာပဲဖြစ်ပါတယ်။

အပေါ်က variable သတ်မှတ်ခဲ့တယ့် အဆင့်တွေ အကုန်လုပ်ဆောင်ပြီးရင်တော့ CrowdStrike registry ကနေ image ကို directly pull လုပ်လို့ရဖို့အတွက် pull token တွေကို create လုပ်ပေးရမှာပဲဖြစ်ပါတယ်။

Set variables for the CrowdStrike registry:

./falcon-container-sensor-pull.sh \
-u $FALCON_CLIENT_ID \
-s $FALCON_CLIENT_SECRET \
--dump-credentials

အခုလိုမျိုး run လိုက်တာနဲ့ Output အနေနဲ့ CrowdStrike registry username နဲ့ password ရမှာပဲဖြစ်ပါတယ်။

OUTPUT

CSRegistryUsername:fc-<userName>
CSRegistryPassword:ABC...123

အဲ့ဒီရလာတဲ့ registry Username နဲ့ Password ကို Image Pull လို့ရဖို့အတွက် variables သတ်မှတ်ပေးရမှာပဲဖြစ်ပါတယ်။

Create the pull token to pull images directly from the CrowdStrike registry:

export PARTIALPULLTOKEN=$(echo -n "$FALCON_ART_USERNAME:$FALCON_ART_PASSWORD" | base64 -w 0)
export FALCON_IMAGE_PULL_TOKEN=$(echo "{\"auths\":{\"registry.crowdstrike.com\":{\"auth\":\"$PARTIALPULLTOKEN\"}}}" | base64 -w 0)

Note: The pull token for the CrowdStrike registry does not expire.

Step 4: Add the CrowdStrike Helm chart client

နောက်တစ်ဆင့်အနေနဲ့ CrowdStrike ရဲ့ Helm Chart repo ကိုထည့်သွင်းပေးရမှာဖြစ်ပါတယ်။

helm repo add crowdstrike https://crowdstrike.github.io/falcon-helm
helm repo update
helm repo list

helm repo list လုပ်ကြည့်လိုက်တာနဲ့ crowdstrike repo ကိုမြင်နေရမှာပဲဖြစ်ပါတယ်။

NAME         URL
crowdstrike  https://crowdstrike.github.io/falcon-helm

နောက်ထပ် Falcon sensor repo ကို variables သတ်မှတ်ပေးရပါမယ်။

Set a variable for the Falcon sensor Helm chart:

export FALCON_SENSOR_REPO=crowdstrike/falcon-sensor

Step 5: Install the Falcon sensor on your cluster

အပေါ်ကအဆင့်တွေအားလုံးပြီးသွားပြီဆိုရင်တော့ Falcon sensor ကို ကျွန်တော်တို့ရဲ့ kubernetes cluster ထဲမှာ Install လုပ်လို့ရပီပဲဖြစ်ပါတယ်။

Create a namespace for the sensor and set the security context:

export FALCON_NAMESPACE=falcon-system
kubectl create namespace $FALCON_NAMESPACE
kubectl label ns --overwrite $FALCON_NAMESPACE pod-security.kubernetes.io/enforce=privileged

နောက်ထပ်တစ်ဆင့်အနေနဲ့ pod တွေကို label ထိုးပေးမှာပဲဖြစ်ပါတယ်။ ဒါကတော့ Optional ဖြစ်ပြီးတော့ namespace ထဲမှာရှိနေတဲ့ pod တွေကို specific configuration နဲ့ resources တွေအတွက်ကို policies တွေသတ်မှတ်ရလွယ်ကူစေမှာပဲဖြစ်ပါတယ်။

Install the Falcon sensor in the namespace:

helm install falcon-sensor $FALCON_SENSOR_REPO \
  -n $FALCON_NAMESPACE \
  --set falcon.cid=$FALCON_CID \
  --set node.image.repository=$FALCON_IMAGE_REPO \
  --set node.image.tag=$FALCON_IMAGE_TAG \
  --set node.image.registryConfigJSON=$FALCON_IMAGE_PULL_TOKEN

Install လုပ်တာ successfully ဖြစ်ရင်တော့ အောက်ပါအတိုင်း output ရမှာပဲဖြစ်ပါတယ်။

NAME: falcon-sensor
LAST DEPLOYED: Wed Oct 11 14:20:01 2023
NAMESPACE: falcon-sensor
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing the CrowdStrike Falcon Helm Chart!
Access to the Falcon Linux and Container Sensor downloads at registry.crowdstrike.com are
required to complete the install of this Helm chart. If an internal registry is used instead of registry.crowdstrike.com.
the containerized sensor must be present in a container registry accessible from Kubernetes installation.
CrowdStrike Falcon sensors will deploy across all nodes in your Kubernetes cluster after
installing this Helm chart. The default image name to deploy a kernel sensor to a node is `falcon-node-sensor`.
When utilizing your own registry, an extremely common error on installation is accidentally forgetting to add your containerized
sensor to your local image registry prior to executing `helm install`. Please read the Helm Chart's readme
for more deployment considerations.

အဲ့တာဆိုရင်တော့ falcon-sensor pod တွေ running ဖြစ်မဖြစ်သိအောင်လို့ စစ်ကြည့်ပါမယ်။

kubectl get pod -n falcon-system

Output:

kubectl get pod -n falcon-system
NAME                  READY   STATUS    RESTARTS       AGE
falcon-sensor-2z8nf   1/1     Running   13 (66d ago)   120d
falcon-sensor-ckz89   1/1     Running   9 (66d ago)    120d
falcon-sensor-nfjk2   1/1     Running   7 (66d ago)    120d
falcon-sensor-wvz85   1/1     Running   9 (66d ago)    120d
falcon-sensor-zpjn2   1/1     Running   1 (66d ago)    112d

running ဖြစ်နေပီဆိုတော့ ကျွန်တော်တို့ ရဲ့ deployment state ကအောင်မြင်သွားပီပဲဖြစ်ပါတယ်။

ကျွန်တော်ရေးခဲ့တာ အမှားများပါခဲ့ရင်လဲ လာရောက်ပြောကြားနိုင်ပါတယ်ခင်ဗျ။ အားလုံးပဲ အချိန်ပေးပြီးဖတ်ရှုပေးတယ့်အတွက်ကျေးဇူးတင်ပါတယ်။

Author By: Sc3p73R

Reference: CrowdStrike Documentation

1. Delete Old License Directory

2. Download License Key

3. Install License

4. Review License

Delete Old License Directory.

Download License Key.

အရင်ဆုံး ကျွန်တော်တို့က Licenses Folder ကို Directory မှာ ရှာပြီးဖျက်ပေးရမှာဖြစ်ပါတယ်။ ဖျက်ပြီးသွားရင် အောက်က Step တွေအတိုင်း တစ်ဆင့်ချင်းလုပ်သွားရုံပါပဲ။

License Key ကိုလဲ Portal ကနေ Generate & Download လုပ်ထားပေးဖို့လဲလိုပါတယ်။

Install License Key

A) Go To Backup Exec --> Installation and Licensing

B) Select --> Install Features and Licenses on this Backup Exec Server.

C) Installing Licenses using .SFL files (Offline Installation):

•Click Import License File.

•Select the .SLF file and click Open.

•Click Next.

•Select a Backup Exec edition license to install and click Next.

•Select required features to install and click Next.

•Select the additional languages to be installed and click Next.

•Review install summary and click Install.

•Click Yes to close Backup Exec console and continue installation.

•Installation progress will be displayed.

•Click Finish.

Reviewing License information:

A) Go To Backup Exec --> Installation and Licensing

B) Select License Information

C) License Information page is displays:

ဒါဆိုရင် License Key ထည့်တာ Success ဖြစ်ပါတယ်။

အားလုံးပဲ အချိန်ပေးပြီး ဖတ်ရှုပေးတဲ့အတွက်လဲ ကျေးဇူးတင်ပါတယ် ခင်ဗျ။

Author By PoneMyat

ပထမဦးဆုံး Zabbix ကို Download & Install လုပ်ထားရပါမယ်။

Install လုပ်ပြီးရင်တော့ ကျွန်တော်တို့ စပြီး Config ချလို့ရပါပြီ။

Configure Zabbix server

1. Open Zabbix server configuration file

vi /etc/zabbix/zabbix_server.conf

2. Change StartVMwaeCollectors parameter

    ### Option: StartVMwareCollectors
           #       Number of pre-forked vmware collector instances.
           #
           # Mandatory: no
           # Range: 0-250
           # Default:
           # StartVMwareCollectors=0
   
           StartVMwareCollectors=2
   

3. Restart Zabbix Server.

    systemctl restart zabbix-server
   

Configure Zabbix Frontend

1. Login to Zabbix

2. Create Host in Zabbix.

   In the Host name field, enter a host name (for example, "VMware environment").

   In the Templates field, type or select the "VMware FQDN" (or "VMware") template.

   In the Host groups field, type or select a host group (for example, a new host group "VMware").

   

   • In the Macros tab, set the following host macros:

     {$VMWARE.URL} - VMware service (vCenter or ESXi hypervisor) SDK URL (https://servername/sdk)

     {$VMWARE.USERNAME} - VMware service user name

     {$VMWARE.PASSWORD} - VMware service {$VMWARE.USERNAME} user password

   • 

3. Click Add to create host.

View collected metrics

Zabbix is already monitoring your VCenter.

To View Create Host, navigate to Data Collection » Hosts

To View Collected Metrics, navigate to Monitoring » Hosts

အခုဆိုရင်တော့ Zabbix ကို အသုံးပြုပြီး ကိုယ့်ရဲ့ VCenter ကို Monitor လုပ်လို့ရပြီပဲဖြစ်ပါတယ်။

အဆင်ပြေကျမယ်လို့ မျှော်လင့်ပါတယ် ။ အားလုံးပဲ အချိန်ပေးပြီး ဖတ်ရှုပေးတဲ့အတွက်လဲ ကျေးဇူးတင်ပါတယ် ခင်ဗျ ။

Author By PoneMyat

Demo အနေနဲ့ကိုတော့ ကျွန်‌‌တော်ကတော့ html file တစ်ခုကိုအသုံးပြုပြီး static website အနေနဲ့ host လုပ်ပြသွားပါမယ်. So let’s get started ။

ပထမဆုံးအနေနဲ့ Amazon Portal ‌ကိုအရင်ဝင်ပြီး‌ ပြီး‌တော့ S3 bucket တစ်ခုကို create အရင်လုပ်ပါမယ် ။

click Search bar and type “S3”

and then click s3 button and create a bucket

create bucket လုပ်ပြီးသွားတဲ့အခါ ပထမဆုံး bucket အတွက် name တစ်ခုပေးရပါမယ် ။ Name ကတော့ ကိုယ်အဆင်ပြေတဲ့ naming ကိုပေးလို့ရပါတယ် ။

ပြီးသွားရင်တော့ ဒီနေရာမှာသတိထားရမှာက Block public access ပါပဲ, AWS က default အရ bucket ကို public access မရအောင် block လုပ်ထားပါတယ် ။

အကယ်၍ block public access ကို off မလုပ်ခဲ့ရင်တော့ user တွေက bucket ကို public ကနေ access လုပ်လို့ရမှာမဟုတ်ပါဘူး ။ ဒီတော့ ကျွန်တော်တို့ block access ကို untick လုပ်ပြီး‌တော့ current setting changes လုပ်ထားတာကို acknowledge လုပ်ပါတယ်ဆိုပြီး box မှာ tick လုပ်‌ပေးရပါမယ် ။

ပြီးရင်တော့ ကျန်တဲ့ setting တွေကို default အတိုင်းထားပြီး bucket ကို create လုပ်လိုက်ပါမယ် ။

ဒါဆိုရင်တော့ S3 dashboard မှာ create လုပ်ထားတဲ့ bucket လေးပေါ်လာပါပြီ ။

အခုကျွန်တော်တို့ backet create လုပ်ပြီးသွာပြီဆိုတော့ website အတွက်လိုအပ်တဲ့ content file ကို upload လုပ်ပါမယ် ။ Upload လုပ်ဖို့အတွက် create လုပ်ထားတဲ့ bucket ကို double click လုပ်ပြီးတော့ဝင်ပြီး file ကို upload လုပ်ပေးရပါမယ် ။

Demo မှာ‌‌တော့ html file ‌‌လေးကို upload လုပ်ပြီးသုံးထားပါတယ်. Add file ကိုနှိပ်ပြီး content file ကို ရွေးပြီး upload လုပ်လိုက်ယုံပါပဲ ။

ပြီးရင်တော့ upload ကို click လုပ်ပြီး save လုပ်လိုက်ရပါမယ် ။

Now the file has been uploaded.

File upload လုပ်ပြီးသွားတဲ့အခါကျရင် bucket က static website hosting လုပ်လို့ရအောင် static website hosing feature ကို on လုပ်ပေးရပါမယ် ။ Feature ကို on လုပ်ဖို့ဆိုရင် Properties ထဲကိုသွားရပါမယ် ။

Scroll down to the end . Static website hosting ဆိုပြီးတွေ့ပါလိမ့်မယ် ။ Edit button ကို click လုပ်ပြီးတော့ enable box ကို tick လုပ်ပေးပြီး‌‌တော့ index document ဆိုတဲ့နေရမှာ index.html ဆို ပြီး ဖြည့်ရပါမယ် ပြီးရင်တော့ကျန်တာကို default အတိုင်းထားပြီး save changes လုပ်လိုက်ပါမယ် ။

အခု static website hosting feature ကို enable လုပ်ပြီးသွားပြီဆိုတော့ နောက်ထက်တစ်ခုအနေနဲ့ bucket အတွက် policy တခုကို attach လုပ်ပေးရပါမယ် ။ Policy attach လုပ်ဖို့ဆိုရင် Permission tab ထဲက bucket policy ထဲမှာသွားပြီး edit လုပ်ပေးရပါမယ် ။

Edit လုပ်တဲ့အခါမှာ policy ရဲ့ resource နေရာမှာကိုယ့်ရဲ့ bucket name ကိုထည့်ပေးရပါမယ် ။ ဒီနေရာမှာတော့ ကျွန်တော် bucket create လုပ်ထားတဲ့ name ဖြစ်တဲ့ vitaltechmyanmar ဆိုတာကိုထည့်လိုက်မှာဖြစ်ပါတယ် ။

ပြီးသွားရင်တော့ scroll down ‌and save changes လုပ်လိုက်ပြီးရင်ရပါပြီ ။ ဒါဆိုရင် ကျွန်တော်တို့ website hosting လုပ်တဲ့ step တွေပြီးသွားပြီဆိုတော့ website ကို access တာအဆင်ပြေလားမပြေလားတချက်ကြည့်ကြည့်ရအောင် ။

ကျွန်တော်တို့ create လုပ်ထားတဲ့ website က accessရမရစမ်းဖို့အတွက်ဆိုရင်တော့ bucket ထဲက index.html ထဲကိုဝင် ပြီးတော့ properties ထဲက Object URL ကို copy လုပ်ပြီး တခြား tab တစ်ခုမှာ paste လုပ်ကြည့်ပါမယ် ။

ဒါဆို ကျွန်တော်တို့ host လုပ်ထားတဲ့ static website လေးကို public ကနေ access လုပ်လိုရသွားပါပြီ .......

အခုဆိုရင်တော့ကျွန်တော်တို့က static website တစ်ခုကို amazon ရဲ့ s3 bucket ကိုအသုံးပြုပြီးတော့ လွယ်လွယ်ကူကူတည်ဆောက်သွားတာဖြစ်ပါတယ် ။ အဆင်ပြေကျမယ်လို့ မျှော်လင့်ပါတယ် ။ အားလုံးပဲ အချိန်ပေးပြီး ဖတ်ရှုပေးတဲ့အတွက်လဲ ကျေးဇူးတင်ပါတယ် ခင်ဗျ ။

ကျနော်ဒီနေ့ Sharing လုပ်ပေးမှာကတာ့ Google Cloud Platform (GCP) ပေါ်မှာ terraform နဲ့ Infrastructure တစ်ခုကို ဘယ်လို တည်ဆောက်မလဲ ဆိုတာ ပြော‌‌ပြ ပေးသွားမှာဖြစ်ပါတယ် ။

ပထမဆုံး အနေ နဲ့ Terraform ဆိုတာဘာလဲ၊ Terraform ကို ဘာလို့ သုံးသင့်တယ် ဆိုတာ အကျဉ်းချုပ်အနေ နဲ့ မိတ်ဆက်ပေးပါမယ်။ ဒီမှာတာ့ Terraform ကို deep မပြောတော့ပါဖူး ။ ဘာလို့ဆို ဒါကို ဖတ်ပြီဆိုတည်းက Terraform ကို ဘာကြောင့် သုံးလဲ ဆိုတာ သိမယ် ထင်လို့ပါ ။ အခု blog မှာလဲ Terraform ကို အသေးစိတ် ရှင်းပြတာမဟုတ်လို့ Terraform နဲ့ Infrastructure ဘယ်လို တည်ဆောက်မလဲ ဆိုတာ ပြောပြမှာ ဖြစ်လို့ပါ။

Terraform Overview

Terraform ဆိုတာ HashiCorp ကထုတ် ပေးထားတဲ့ Infrastructure as Code (IaC) နည်းပညာတစ်ခုဖြစ်ပါတယ်။ ဒီ tool ကိုအသုံးပြုပြီး Infrastructure ကို building, changing, managing လုပ်နိုင်ပြီး safe ဖြစ်စွာ ထပ်ခါထပ်ခါ အသုံးပြုနိုင်ပါတယ် ကိုယ့်လူတို့ ဘယ်လောက်မိုက်လဲ ဒီ tool ကြီးက အမြဲတမ်း ထပ်ခါခါ ခေါင်း မကိုက်ချင်တဲ့ ကိုယ်တွေ အတွက် အဆင်ပြေတယ် ။Operator နဲ့ Infrastructure team တွေက ဒီ tool ကိုအသုံးပြုပြီး environment တွေကို automated deployment လုပ်ဖို့ (HCL )လို့ခေါ်တဲ့ သုံး HashiCorp Configuration Language ကိုသုံးထား တယ် ။ HCL က Human-readable ဖြစ်တဲ့ အတွက် ဖတ်ရတာ လွယ်ကူတယ် ကျက်ရတာ လွယ်ကူတာ မဟုတ်ဖူးနော် ။ IaC လို့ ပြောခဲ့တယ် နော် IaC ဆိုတာက User Interface မှာ သုံးရတာမဟုတ်ပဲ file ထဲ မှာ Configuration ထည့်ပြီး Infrastructure ကို management လုပ်ရတာကို ပြောချင်တာ ပါ။ Configuration ထဲမှာ Resources တွေထည့်ရမှာ Resource type/name တို့ Resources ဆိုတာ Infrastructure ရဲ့ အစိတ် အပိုင်းတွေ ဖြစ်တဲ့ VM, Security Group, Network Interface, etc...blah blah ပေါ့နော်။ အဲ့မှာ Resources ဆိုလို့ ပြောရဦးမယ် Terraform က ဘယ် Provider အတွက်လဲ ဆိုတာ အရင် အသိပေးရမှာပါ AWS လား Azure လား GCP လား Docker လား တစ်ခြား Provider တွေလဲ အများကြီးရှိပါသေးတယ် အဲ့တာမှ ဘယ် Provider ရဲ့ resources ဆိုတာ သိမှာ ဖြစ်ပါတယ်။

Terraform မှာပုံမှန် လုပ်ဆောင်ရမယ့် flow လေးတွေပြောပြပါမယ်

-Scope : ပေးထားတဲ့ Project အတွက် ဘယ် resources တွေလဲ ဆိုတာ အရင် Confirm လုပ်ရပါမယ်

-Author : Scoped parameter ပေါ်မူတည်ပြီး HCL နဲ့ Configuration file ရေးရပါမယ်

-Initialize : Project Directory အတွင်းမှာ Terraform init command run လိုက်မှသာ Project အတွက် လိုအပ်တဲ့ Provider plug-in download လုပ်သွားမှာဖြစ်ပါတယ်။

-Plan : Terraform plan ဆိုတဲ့ command run ရမှာပါ ဘာလို့ဆို ငါတို့ ဘာလုပ်ချင်တယ် ဆိုတာ ကြိုတင် ပြပေးတာပါ အကယ်၍ လိုအပ်တာ/မလိုအပ်တာ ရှိရင် ပြန်ပြင်လို့ ရအောင်ပါ။ အမှားအယွင်း နည်းအောင် ပေါ့။

-Apply : Terraform apply command က Configuration ထဲ အတိုင်း အကုန် အကောင်အထည် ဖော်တော့မှာပါ ။ State file ပါ တစ်ခါတည်း ဖန်တီး ပေးသွားမှာပါ။

State file ဆိုတာက တော့ လုပ်သမျှ Configuration တွေကို အဲ့ထဲမှာ မှတ်ပြီး ပြန်သုံးလို့လဲ ရသလို modify လဲ ပြန်လုပ်လို့ရပါတယ် ။ အဲ့ State file ကြောင့် Project တစ်ခုလုံး တစ်ခါထဲလဲ destroy လုပ်လို့ရပါတယ် ၊အမှားအယွင်းဖြစ်မှာ စိုးရိမ်ရင် backup လုပ် ကိုလုပ်သင့်ပါတယ်။ ‌‌

State file ရဲ့ feature တွေက Meta Data တွေကို Map လုပ်ပေးတယ်၊ Performance ပိုကောင်းစေတယ် (cache function)၊ Syncing လုပ်ပေးတယ် ၊ State Locking လုပ်ပေးတယ် ၊ Workspaces ခွဲပေးထားတယ် ၊ ဘာတွေလဲ ဆိုတာကတော့ ရှာဖတ်လိုက်တာ့ ရှင်းပြရင် အရမ်းရှည်သွားမှာဆိုးလို့။

ကဲ အဲ့လောက် ဆိုရင် အခုလုပ်ပြမဲ့ Infrastructure တည်ဆောက်တာကို စလိုက်ကြရအောင်ပါ။ အဓိက Project တစ်ခုလုံး မဟုတ်ပါဖူး အခြေခံ နဲ့ Sample အနေနဲ့ ပြမှာ ဖြစ်ပါတယ် ။

Step 1 : Create the configuration files

ပထမဆုံး ဒီ Lab အတွက်လိုအပ်တဲ့ Configuration file တွေအရင် တည်ဆောက်ပါမယ်။

Google Cloud Console ကို၀င်ပါ ။Activate Cloud Shell ကိုနှိပ်ပါ ။

အရင်ဆုံး account name ကိုစစ်ပါ ။

gcloud auth list

ကိုယ် အသုံးပြုမဲ့ project id မှန်မမှန်စစ်ပါ။

gcloud config list project

mkdir -p modules/instances modules/storage
touch main.tf variables.tf
touch modules/instances/{instances.tf,outputs.tf,variables.tf}
touch modules/storage/{storage.tf,outputs.tf,variables.tf}

main.tf
variables.tf
modules/
└── instances
    ├── instances.tf
    ├── outputs.tf
    └── variables.tf
└── storage
    ├── storage.tf
    ├── outputs.tf
    └── variables.tf

အခုလက်ရှိမှာ main.tf နဲ့ variables.tf က Root အနေနဲ့ ရှိနေပါတယ် သူတို့က အဓိကလုပ်ဆာင်မှာပါ။ Modules အောက်မှာရှိနေတဲ့ instances နဲ့ Storage ကို module အနေနဲ့ ခေါ်သုံးမှာ ဖြစ်ပါတယ် local module ပေါ့ဗျာ။ Terraform Registry မှာ လဲ module တွေခေါ်သုံးလို့ရပါတယ် ။ဒီ lab မှာလဲ registry ကခေါ်သုံးတာပြ ပေးမှာပါ။အောက်က ပုံထဲက အတိုင်း Cloud Shell မှာ Open Editor လေးရှိပါတယ် နှိပ်လိုက်ပါ

Step 2 : Build infrastructure

Cloud Shell မှာ ပေါ်နေတဲ့ Editor ဆိုတာလေးဖွင့်လိုက်ပါ ကျနော်တို့ခုနက ဆောက်ထားတဲ့ root variables.tf ဆိုတဲ့ file ထဲမှာ variables တွေကိုကြေညာပါမယ်။

variable "region" {
  default = "us-east4"
}

variable "zone" {
  default = "us-east4-a"
}

variable "project_id" {
  default = "your project id"
}

‌ဒါက instance နဲ့ storage modules ရဲ့ variables တွေဖြစ်ပါတယ်။ အဓိကကတော့ root ရဲ့ variables ကိုပဲ main.tf ကယူသုံးမှာဖြစ်ပါတယ်။ instance နဲ့ storage modules ရဲ့ variables.tf file မှာထည့်ပါမယ်။

variable "region" {
  type = string
}

variable "zone" {
  type = string
}

variable "project_id" {
  type = string
}

main.tf file မှာ ကိုယ်သုံးမည့် Provider ကို အရင်ကြေညာပေးရမှာပါ

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.0"
    }
  }
}

provider "google" {
  project = var.project_id
  region  = var.region
  zone    = var.zone
}

VPC တည်ဆောက်ဖို့ အတွက် main.tf file ထဲသို့ ထပ်ထည့်ပါ။

resource "google_compute_network" "vpc_network" {
  name = "terraform-network"
  auto_create_subnetworks  = false
}
resource "google_compute_subnetwork" "subnet_1" {
  name          = "subnet-1"
  ip_cidr_range = "10.10.10.0/24"
  region        = var.region
  network       = google_compute_network.vpc_network.self_link
}

Provider အတွက် လိုအပ်တဲ့ plug-in download ယူရန်နှင့် အကောင်ထည် ဖော်ဖို့အတွက် အောက်ပါ commands တွေ ကို တစ်ခုချင်းဆီ Run ပါ။

terraform init
terraform plan
terraform apply

Google Cloud Console ကနေ စစ်ကြည့်ပါ terraform-network ဆိုတဲ့ VPC လေး create လုပ်ပြီးပါပြီ

Step 3 : Create Instances

Instances Modules မှ instances များကို ခေါ်သုံးမှာ ဖြစ်တဲ့ အတွက် instances.tf file ထဲ instances အတွက် Configuration ကို အရင် ရေးရပါမယ်

resource "google_compute_instance" "instance-1" {
  name         = "instance-1"
  machine_type = "e2-standard-2"
  boot_disk {
    initialize_params {
      image = "debian-11-bullseye-v20240815"
    }
  }
  network_interface {
    network = var.network_name
    subnetwork = var.subnet_name
  }
}

resource "google_compute_instance" "instance-2" {
  name         = "instance-2"
  machine_type = "e2-standard-2"
  boot_disk {
    initialize_params {
      image = "debian-11-bullseye-v20240815"
    }
  }
  network_interface {
    network = var.network_name
    subnetwork = var.subnet_name
  }
}

instances.tf file ထဲမှာ network_interface မှ ခေါ်သုံးဖို့ အတွက် instances module ရဲ့ variables.tf file ထဲ ထည့်ပါ

variable "network_name" {
  description = "The name of the Google Compute Network"
  type        = string
}
variable "subnet_name" {
  type = string
}

Instance module ကို main.tf file တွင် ညွှန်းပေးရပါမယ်။ အဲ့တာမှ instance.tf file ထဲ configuration ကိုယူသုံးမှာဖြစ်ပါတယ်။ Source မှန်အောင် ထည့်ဖို့ လိုအပ်ပါတယ်။

module "instances" {
  source    = "./modules/instances"
  region    = var.region
  zone      = var.zone
  project_id = var.project_id
  network_name = google_compute_network.vpc_network.self_link
  subnet_name = google_compute_subnetwork.subnet_1.self_link
}

အပြောင်းအလဲ လုပ်ပြီးတိုင်း လုပ်ဆောင်ပါ။

terraform init
terraform plan
terraform apply

instance-1 နှင့် instance-2 ဖန်တီးပြီး ဖြစ်ကြောင်း တွေ့ရပါလိမ့်မယ်

cloud console တွင် instance-1 ကိုနှိပ်ပြီး ပေးထားတဲ့ machine type, boot_disk, Network မှန်/မမှန်စစ်ဆေးကြည့်ပါ

Step 4 : Import Infrastructure

Import Infrastructure ဆိုတာကတော့ ကျနော်တို့က user interface ကနေ manual ဆောက်ထားတဲ့ objects တွေက Terraform နဲ့ ဆက်စပ်မူ မရှိပါဖူး ။ Manual ဆောက်ထားခဲ့ resources တွေကို Terraform နဲ့ manage လုပ်ချင်တယ် ဆိုရင် Terraform state file ထဲကို import လုပ်ပေးရမှာ ဖြစ်ပါတယ် ။ ဘယ်လို လုပ်ရမလဲ ပြောပြ ပေးပါမယ်။ အရင်ဆုံး ကိုယ် import လုပ်ချင်တဲ့ VM ရဲ့ machine type, boot-disk, network_interface, တွေကို configuration file မှာ တူအောင် ရေးရပါမယ် ။ အဲ့မှာ အရေးကြီး တာက meta_startup_script နဲ့ allow_stopping_for_update ကို ထည့်ပေးရမှာပါ ။ ကျနော် example တစ်ခု ပြပါမယ်

resource "google_compute_instance" "tf-instance-1" {
  name         = "tf-instance-1"
  machine_type = "e2-standard-2"
  boot_disk {
    initialize_params {
      image = "debian-11-bullseye-v20240815"
    }
  }
  network_interface {
    network = "default"
  }
  metadata_startup_script = <<-EOT
    #!/bin/bash
  EOT
  allow_stopping_for_update = true
}

ကျနော် အခု ပြထားတာ example configuration ပါ machine type တွေ name တွေ boot_disk တွေ network_interface တွေ ကိုယ် import လုပ်ချင်တဲ့ instance အသုံးပြုထားတဲ့ အတိုင်း ပြန် ပြင်ပါ ။ ပြောချင်တာ ရောက်လာပါပြီ metadata_startup_script ဆိုတာ VM up တဲ့အခါ အလိုအလျောက် လုပ်ဆောင်မည့် script ပါ bash script နဲ့လုပ်မယ်လို့လဲ ကြေညာထားပါတယ် အဲ့ VM ထဲမှာ run software တွေ setting တွေ configure ချထားတာ တွေ automated ပြန်လုပ်ပေးမယ် ပြောတာပါ ။ allow_stopping_for_update ကို true လို့ သတ်မှတ်ထားတာက instance ကိုပြန်ဖျက်ပြီး အသစ် ပြန်ဖန်တီး စရာမလိုပဲ update လုပ်ဖို့ အတွက်ပါ ။ဒါက instance configuration ကို downtime မရှိပဲ ပြင်ဖို့ အထောက်အကူ ပေးတာပါ ။ ဒီလောက်ဆို နားလည်မယ် ထင်ပါတယ် ။ကျနော်တို့ ဆက်သွားပါမယ် ။

အဲ့တာ တွေ အကုန်ပြီးသွားရင် import စလုပ်ပါမယ် ။ instance တွေကို import လုပ်ပါမယ် ။ အခု အောက်မှာ ပြထားတဲ့ Terraform import command နဲ့ import လုပ်ပါမယ် ။ ဒီနေရာမှာ မင်းအခု module အောက်မှာ ရေးထားတဲ့ configuration နဲ့ import လုပ်ချင်တဲ့ instance ရဲ့ instance id နဲ့ map လုပ်ပေးပါ ။ VM ပဲ သုံးသုံး instance ပဲ သုံး သုံး အတူတူပဲ လို့ယူဆပေးပါ အခေါ်အဝေါ်ပဲ ကွဲတာမို့။import လုပ်ရင် သတိထားရမှာက import လုပ်ထားတဲ့ instance တိုင်းကို Terraform က life cycle management ဖြစ်တဲ့ အတွက် Terraform destroy run အကုန် ပျက်မှာဖြစ်ပါတယ်

စာဖတ်သူ import လုပ်ချင်တဲ့ instance ရဲ့ id ကိုယူပြီး အောက်ပါ command အတိုင်း run ပါ

terraform import module.instances.google_compute_instance.tf-instance-1 <tf-instance-1-id>

terraform init 
terraform apply

Step 5 : Configure a remote backend

ဒါက ဘာကို ‌‌‌ပြောချင်တာလဲ ဆိုရင် Terraform state file ကို remote ကနေ ယူသုံးပြီး modify လုပ်မယ် create လုပ်မယ်ပေါ့ဗျာ ။ အရင်ဆုံး google bucket တစ်ခု ဆောက်လိုက်မယ် ဗျာ။ storage module မှာ storage.tf file မှာ configuration ရေးကြမယ် let's go ။ bucket name က unique ဖြစ်ရမယ် နော် ။

resource "google_storage_bucket" "bucket_01" {
  name                        = "qwiklabs-gcp-00-3712a4245aff"
  location                    = "US"
  force_destroy               = true
  uniform_bucket_level_access = true
}

နောက်တစ်ဆင့် module ကို main.tf file ထဲမှာ ပြန်ညွှန်းမယ် ။

module "storage" {
  source    = "./modules/storage"
  project_id = var.project_id
  region    = var.region
  zone = var.zone
}

terraform init
terraform plan
terraform apply

Bucket တစ်ခု ဖန်တီးထားကြောင်း တွေ့ရပါလိမ့်မယ် ။ bucket name က unique ဖြစ်လို့ ကျနော် က project id ထည့်သုံးထားတာပါ။

နောက်တစ်ဆင့် cloud bucket ပေါ် remote backend ကိုတင်ဖို့ main.tf file ထဲ ထည့်ရမယ် ။ ပြောရမယ် ဆို ဒီ Terraform state file တစ်ခုထဲ မှာ store လုပ်ထားတဲ့ configuration တွေ Workspace လို့ခေါ်တယ် ပေါ့ဗျာ။

terraform {
  backend "gcs" {
    bucket = "qwiklabs-gcp-00-3712a4245aff"
    prefix = "terraform/state"
  }
}

terraform init

အခုဆို Terraform ဆိုတဲ့ state file ရဲ့ folder လေးရာက် နေပါပြီ

Remote backend ကို local ကို revert ပြန်လုပ်ချင်ရင် main.tf file တွင် အောက်ပါ configuration ကို change ပါ

terraform {
  backend "local" {
    path = "terraform/state/terraform.tfstate"
  }
}

-migrate-state argument ကို ထည့်ပေးရမယ် ။

terraform init -migrate-state

ls command နဲ့ စစ်ကြည့်ပါ local ထဲကို ပေးထားတဲ့ PATH အတိုင်း ရောက် နေပါပြီ

Step 6 : Modify and update infrastructure

နမူနာ အနေ နဲ့ Infrastructure ကို Modify လုပ်ပြမယ် ။ အခု လုပ်ပြမှာက instance တစ်ခုကို ထပ် add ပြပါမယ် ။ Instance.tf file ထဲတွင် ထပ် ထည့်ပါ။

resource "google_compute_instance" "instance-3" {
  name         = "instance-3"
  machine_type = "e2-standard-2"
  boot_disk {
    initialize_params {
      image = "debian-11-bullseye-v20240815"
    }
  }
  network_interface {
    network = var.network_name
    subnetwork = var.subnet_name 
  }
}

terraform apply

အခုဆို instance-3 ဆိုတဲ့ instance လေးတစ်လုံးထပ်ရာက် နေပါပြီ

နောက်တစ်ခုက အခု ထပ်ထည့်လိုက်တဲ့ instance ကိုပဲ ဖျက်ပြမှာပါ ။ Instance.tf file မှာ instance အသစ် အတွက် Configuration ကို ဖျက်ပစ် လိုက် ။ ဒါမှ မဟုတ် # sign ခံပြီး comment ပိတ် လိုက် ရပါတယ် ။ ပြီးသွားရင် Terraform apply command ပြန်run ပါ။

terraform apply

configuration ပြင်ပြီး apply ပြန်စစ် ကြည့်ပါ instance မရှိတော့ကြောင်း တွေ့ရပါလိမ့်မယ်

ဒါက ကျနော်တို့က Terraform ကနေ manage လုပ်တာ ဖြစ်ပါတယ် ။အကယ်၍ ကျနော်တို့ က user interface ကနေ change လိုက် တယ် tag တို့ label တို့ အစရှိ သဖြင့်ပေါ့ ဗျာ အဲ့တာဆို ရင် state file မှာပါ update ဖြစ်အောင် ‌‌‌‌refresh ဆိုတဲ့ command နဲ့ update လုပ်ရမှာဖြစ်ပါတယ်။ ဥပမာ အနေ နဲ့ ကျနော် အပေါ် ‌create လုပ်ထားခဲ့ တဲ့ bucket file ကို label ထည့်ပြပါမယ် ။ Bucket ကို အမှန်ခြစ် ပေးပြီး LABELS ကိုနှိပ်လိုက်ပါ

ဒီမှာဆို Add Label နှိပ်ပြီး key နဲ့ value ဆိုပြီးပေးခဲ့ပါတယ် ။Save ခဲ့ပါ

ပြီးရင် Terraform state file မှာ update လုပ်ဖို့ refresh ဆိုတဲ့ command ကို runပါ

terraform refresh

ပြီးရင် Terraform state file မှာ update ဖြစ်လား ပြန်ကြည့်ဖို့ အောက်ပါ command ကို run ပါ

terraform show

အခုဆို label ပေးထားခဲ့တဲ့ key နဲ့ value ကိုမြင်နရပါပြီ

Step 7 : Configure a Firewall

အခု တစ်ခါ မှာ တော့ အပေါ်မှာ ဆောက်ထား ခဲ့တဲ့ VPC network ကို All IP (0.0.0.0/0)ကို Port 80 ကနေ ingress connection ကို allow ပေးမှာ ဖြစ်ပါတယ် ။ ဒီတော့ main.tf file မှာ firewall resources တွေကို ကြေညာပါမယ် ။

resource "google_compute_firewall" "tf-firewall" {
  name    = "tf-firewall"
  network = google_compute_network.vpc_network.name

  allow {
    protocol = "tcp"
    ports    = ["80"]
  }

  source_ranges = ["0.0.0.0/0"]
}

terraform init
terraform apply

အခုဆို tf-firewall ဆိုတဲ့ firewall rule ကိုတွေ့ရပါလိမ့်မယ်

Step 8 : Use a module from the Registry

အခု ပြောပြ ပေးမဲ့ အရာက တော့ Network module ကို Terraform Registry ကနေ ခေါ်သုံးမှာ ဖြစ်တယ် ။ အ‌‌ပေါ်မှာ ပြောပြခဲ့တာတွေက local မှာပဲ module ကို တည်ဆောက်ပြီး ပြောပြခဲ့တာတွေပါ ။ Version 6.0 ကို သုံးပြပါမယ် ။ Main.tf file ထဲမှာ ထည့်ပါ ။ Subnets 2 ခုနဲ့ ဆောက်ပြ ပေးထားပါတယ် ။

module "vpc" {
  source  = "terraform-google-modules/network/google"
  version = "6.0.0"

  project_id   = var.project_id
  network_name = "test-vpc"
  routing_mode = "GLOBAL"

  subnets = [
    {
      subnet_name   = "subnet-01"
      subnet_ip     = "10.10.20.0/24"
      subnet_region = var.region
    },
    {
      subnet_name   = "subnet-02"
      subnet_ip     = "10.10.30.0/24"
      subnet_region = var.region
    },
  ]
}

Terraform Registry ရဲ့ source ကိုမှန် အောင်ထည့်ပါ။ အောက်မှာ link ချပေးထားပါတယ် ။

https://registry.terraform.io/modules/terraform-google-modules/network/google/6.0.0

terraform init
terraform apply

Terraform Registry မှ ယူသုံးထားတဲ့ Network Module နဲ့ create လုပ်ထားတဲ့ VPC လေး တွေ့ရပါလိမ့်မယ်

Step 9 : Destroy Infrastructure

Terraform နဲ့ ဖန်တီးတဲ့ အရာတွေ အကုန်ဖျက်ချင်ရင် destroy ဆိုတဲ့ command နဲ့ ဖျက်လို့ပါတယ် ။ command run ပြီးတဲ့ အခါ စတင်ဖျက်မဲ့ resources list တွေ ပြပြီး အတည်ပြချက် တောင်းဆိုပါတယ် ။terraform state file ကနေ ကြည့်ပြီး အကုန် ဖျက်ပစ်မှာ ဖြစ်ပါတယ်

terraform destroy

ကျနော် ဆောက်ထားခဲ့တဲ့ resources တွေ အကုန်ဖျက်သွားမည် ဖြစ်တယ် ။Google Cloud Console တွင် ပြန်ကြည့်ကြည့်ပါ ဘာမှ မရှိတော့ ဖူး ကြည့်မ နေနဲ့ 😁

ဒီစာကို ဒီလောက်နဲ့ ပဲ နားပါမယ် စာဖတ်သူ တွေ တစ်ခုခု ရမယ်လို့ မျော် လင့်ပါတယ် ။

Author by Kyaw Thet Htun

My Linkedin Profile - https://www.linkedin.com/in/kyaw-thet-htun/

အရင်ဆုံး ကျွန်တော်တို့ Text Document အလွတ်တစ်ခု Create လုပ်ပါမယ်။ ပြီးရင် ကျွန်တော် command လေး ထည့်ပါမယ်။ Command ကို အောက်မှာ copy ယူပါ။

@echo off & cls

set IP=8.8.8.8

:top

PING -n 1 %IP% | FIND "TTL="

IF ERRORLEVEL 1 (
    SET OUT=4F
    echo Request timed out.
) ELSE (
    SET OUT=2F
)

color %OUT%

ping -n 2 -w 1000 127.0.0.1 >nul

GoTo top

set IP = 8.8.8.8 နေရာမှာ ကိုယ် Ping ထားချင်တဲ့ Server IP ဒါမှမဟုတ် Website (amazonaws.com) စသဖြင့် ကိုယ်ထားချင်တဲ့ဟာကို ပြောင်းထားလို့ရပါတယ်။

ပြီးရင် ကျွန်တော်တို့ Text File လေးကို Save ပါမယ်။ Save တဲ့အခါ bat file အနေနဲ့ Extension ပြောင်းပြီး save ပေးရပါမယ်။

ဒီ ping.bat File လေးကို Double Click or Run As Administrator နှိပ်ပြီး Run လိုက်မယ်ဆိုရင်

reply ပြန်ရင် Background က စိမ်းနေမှာဖြစ်ပြီး

reply မပြန်ရင် Background က အနီရောင်ဖြစ်နေမှာပါ။

Ping ပြန်မိသွားရင်တော့ Background က ပြန်စိမ်းလာမှာပဲဖြစ်ပါတယ်။

ဒီ Tips & Trick လေးက လွယ်ကူပြီး ရိုးရှင်းတဲ့အတွက် အသုံးတည့်မယ်လို့ မျှော်လင့်ပါတယ်။ အားလုံးပဲ အချိန်ပေးပြီး ဖတ်ရှုပေးတဲ့အတွက်လဲ ကျေးဇူးတင်ပါတယ် ခင်ဗျ။

Author By PoneMyat

အားလုံးပဲ မင်္ဂလာပါခင်ဗျ၊ ကျွန်‌တော် ဒီနေ့ပြောပြပေးသွားမှာကတော့ ADVPN အကြောင်းလေးပဲဖြစ်ပါတယ်၊ Auto Discovery VPN (ADVPN) က Spoke sites တွေက topology ရဲ့ Hub ကို route မသွားတော့ပဲ Spoke တစ်ခုနဲ့တစ်ခု လိုအပ်ချက်အရ direct tunnels (dynamic) တွေရဖို့ အသုံးပြုတဲ့ IPsec Technology ရဲ့ traditional hub and spoke vpn ဖြစ်ပါတယ်၊

ADVPN ရဲ့ main advantage ကတော့ hub and spoke topology မှာ full mesh ပေးနိုင်တာပဲဖြစ်တယ်၊ ၎င်းက spoke to spoke ကြား connection အပြည့်အဝရရှိဖို့အတွက် delay ဖြစ်မှုကို ‌လျှော့ချ‌ပေးတယ်၊ နောက် အလွန်ကြီးမားတဲ့ full mesh VPN network က issues တွေကိုလဲ ဖြေရှင်းပေးနိုင်တယ် ဖြစ်ပါတယ်၊

Hub နဲ့ Spoke offices တွေမှာ internet connections နှစ်ခု(or)နှစ်ခုထက်ပိုရှိရင် dual-hub ADVPN network လဲတည်ဆောက်နိုင်သလို၊ SD-WAN technology သုံးပြီး Spoke offices တွေကို dynamic tunnels ‌တွေနဲ့ user တွေရဲ့ traffic တွေကို load balance အနေနဲ့လဲ အသုံးပြုနိုင်မယ် ဖြစ်ပါတယ်၊

How to Config ADVPN on Fortigate Firewall?

Topology အနေနဲ့ကတော့ Hub တစ်ခု၊ Spoke နှစ်ခုနဲ့ သုံးပြသွားမှာဖြစ်ပါတယ်၊

ADVPN ကတော့ other spokes တွေရဲ့ routesတွေကို affect မဖြစ်စေပဲ spoke နှစ်ခုကြား route traffic တွေ peer connection တွေရှိစေဖို့ internal routing protocol တစ်ခုသုံးပေးဖို့လိုအပ်ပါတယ်၊

Fortigate ရဲ့ ADVPN ကတော့ internal routing protocol အနေနဲ့ BGP, OSPF, RIP တွေကို support တယ်၊ အဲ့တော့ ကိုယ်နှစ်သက်တဲ့ routing protocol ကိုအသုံးပြုနိုင်ပါတယ်၊ ဒီ LAB မှာ‌တော့ ကျွန်တော်က routing protocol ကို iBGP နဲ့သုံးသွားမှာဖြစ်ပါတယ်၊

ပြီးသွားရင်တော့ hub and spoke tunnel ထိုးမှာဖြစ်တဲ့အတွက် IPsec hub and spoke ကိုအသုံးပြုသွားမှာဖြစ်ပါတယ်၊

Ok, Let’s start with Lab!

Lab Topology

Tasks

Configure BGP settings on FGT-Hub:

1. On FGT-Hub, go to Network > BGP

2. In the Local AS field, enter 65400

3. In the Router ID field, enter 0.0.0.101

   

4. Under Neighbor Groups, click Create New

5. Enter the following settings:

   • Name : Branch-Peers

   • Remote AS : 65400

   • Activate IPv4 : Enable

   • Attribute unchanged : Disable

   • Route Reflector client : Enable

   • Capability: route refresh : Enable

     

6. Click Ok

7. Click Apply to save the BGP settings.

Configure BGP settings on FGT-Spoke1:

1. On FGT-Spoke1, go to Network > BGP

2. In the Local AS field, enter 65400

3. In the Router ID field, enter 0.0.0.111

   

4. Click Apply to save the BGP settings.

Configure BGP settings on FGT-Spoke2:

1. On FGT-Spoke2, go to Network > BGP

2. In the Local AS field, enter 65400

3. In the Router ID field, enter 0.0.0.112

   

4. Click Apply to save the BGP settings.

လိုအပ်တဲ့ routing protocol ကို create လုပ်ပြီးသွားပြီဖြစ်တဲ့အတွက် IPsec VPN (Hub and Spoke) ကို ထပ်မံ create လုပ်သွားမှာဖြစ်ပါတယ်၊

Configuration of IPsec Hub and Spoke

Configure VPN on FGT-Hub with the IPsec Wizard:

1. On FGT-Hub, navigate to VPN > IPsec Wizard.

2. On the VPN Setup page, use the following settings:

   • Name : Branches

   • Template type : Hub-and-Spoke

   • Role : Hub

     

3. Click Next

4. On the Authentication page, use the following settings:

   • Incoming Interface: ISP (port4)

   • Authentication Method: Pre-shared Key

   • Pre-shared Key: Labtest098&

     

5. Click Next >

6. On the Tunnel interface page, use the following settings:

   • Tunnel IP : 10.10.1.101

   • Remote IP/Netmask : 10.10.1.1/24

     

7. Click Next >

8. On the Policy & Routing page, use the following settings:

   • Local AS : 65400

   • Local interface : LAN

   • Local subnet. Click the +button to add more subnets:

     1. 192.168.101.0/24

   • Spoke type : Range

   • Spoke range prefix : 10.10.1.0/24

   • Spoke neighbor group : Branch-Peers

     

9. Click Next >

10. Click Create

    

Spoke ဘက်တွေကိုကျတော့ အလွယ်တကူ config ချလို့ရအောင် Configuration Key ကို Generate ထုတ်သွားရမယ်ဖြစ်ပါတယ်၊ နောက် Spoke sites တွေထပ်တိုးချင်ရင်လဲ ထပ်တိုးလို့ရပါတယ်၊

Configure VPN on FGT-Spoke1 with the IPsec Wizard:

1. On FGT-Spoke, navigate to VPN > IPsec Wizard.

2. On the VPN Setup page, use the following settings:

   • Name : Hub

   • Template type : Hub-and-Spoke

   • Role : Spoke

   • Easy Configuration Key : Spoke #1 ရဲ့ key ထည့်မယ်

3. Click Next >

4. On the Authentication page, use the following settings:

   • Pre-shared key : Labtest098&

     

5. Click Next >

6. On the Tunnel interface page, Click Next >

   

7. On the Policy & Routing page, use the following settings:

   • Local AS : 65400

   • Local interface : LAN

   • Local subnets : 192.168.111.0/24

     

8. Click Next >

9. Click Create

   

ထိုနည်း၎င်းအတိုင်းပဲ Spoke2 ကိုလဲ Spoke1 အတိုင်း config ထပ်လုပ်ရမယ်ဖြစ်ပါတယ်၊

ပြီးသွားရင်တော့ နောက်ဆုံး ကျွန်တော်တို့ Hub ဘက်မှာကော၊ Spoke1, Spoke2 ဘက်တွေမှာပါ VPN Tunnels တွေ up နေပြီဆိုတာ တွေ့ရမှာဖြစ်ပါတယ်၊

အချိန်ခဏနေကြာရင် Spoke to Spoke ကြား direct tunnels တွေထပ် up လာတာကိုတွေ့ရလိမ့်မယ်ဖြစ်ပါတယ်၊

Result အနေနဲ့ကတော့ အပေါ်က ပြောခဲ့သလို Auto Discovery VPN သည် Spoke sites တွေက topology ရဲ့ Hub ကို route မသွားတော့ပဲ Spoke တစ်ခုနဲ့တစ်ခု direct tunnel (dynamic)ကို အသုံးပြုသွားတာ တွေ့ရမှာဖြစ်ပါတယ်၊

Spoke1 ရဲ့ Local ကနေ Spoke2 ရဲ့ Local ကို တကယ်အလုပ်လုပ်မလုပ် testing လှမ်း ping ခြင်းဖြစ်ပါတယ်

Spoke1 ကနေ Spoke2ကို traffic route သွားတာတွေ့ရမှာဖြစ်ပါတယ်၊ ဒါပေမယ့် Hub ဆီကိုတော့ route သွားခြင်းမတွေ့ရပါဘူး၊ Spoke to Spoke direct tunnel အသုံးပြုသွားတာပဲ တွေ့ရမှာဖြစ်ပါတယ်၊ အားလုံးပဲ ကျွန်တော် Lab လေးကို အချိန်ပေးပြီး ဖတ်ရှုပေးတဲ့ ကျေးဇူးတင်ပါတယ် ခင်ဗျ၊ အမှားများပါခဲ့ရင်လဲ ကျွန်တော့်ကို လာရောက်ပြောပြပေးနိုင်ပါတယ်ခင်ဗျ။

ဆိုတော့ ကျွန်တော်တို့ NAS လဲ သုံးချင်တယ်။ ‌Synology NAS တွေကျတော့လဲ စျေးကြီးတယ်။ ဒါဆို ဘယ်လိုလုပ်မလဲ??

Ubuntu As NAS

ကျွန်တော်တို့ သုံးနေတဲ့ Ubuntu ကိုပဲ Samba အသုံးပြုပြီး File Server တစ်ခုအနေနဲ့ Setup လုပ်သွားပါမယ်။

1. Installing Samba

sudo apt update
sudo apt install samba

Check Installation success or not?

whereis samba

The Result may

samba: /usr/sbin/samba /usr/lib/samba /etc/samba /usr/share/samba /usr/share/man/man7/samba.7.gz /usr/share/man/man8/samba.8.gz

2. Setting Up Samba

Samba ကို Install လုပ်ပြီးသွားပြီဆိုတော့ Share ဖို့အတွက် Directory တစ်ခု ဖန်တီးပါမယ်။

mkdir /home/<username>/sambashare/

ဒီ cmd က smabashare ဆိုတဲ့ Folder လေးကို Directory မှာ ဆောက်သွားတာပါ။

samba configuration file က ဒီလမ်းကြောင်းထဲမှာ ရှိတာပါ။ ( /etc/samba/smb.conf )

ကျွန်တော်တို့က ဒီ လမ်းကြောင်းထဲက File ကိုသွားပြီး configure ချပါမယ်။

sudo nano /etc/samba/smb.conf

ဒီ Config လေး ထည့်ပါမယ်။

[sambashare]
    comment = SambaShare
    path = /home/username/sambashare
    read only = no
    browsable = yes

ပီးရင် Save လုပ်ပါမယ်။ save လုပ်ပြီးရင် effect ဖြစ်ဖို့အတွက် service restart ချပေးရပါမယ်။

sudo service smbd restart

နောက်ပြီး Firewall မှာ smb traffic တွေအတွက် Rule update လုပ်ပေးဖို့လိုပါတယ်။

sudo ufw allow samba

3. Setting up User Accounts

User Acc တစ်ခု Create လုပ်ပါမယ်။

sudo smbpasswd -a username

4. Connecting to Share

Ubuntu Share

Mac Share

Windows

\\ip-address\sambashare

အခုဆိုရင်တော့ Ubuntu မှာ File Server Setup လုပ်နည်းလေး သိသွားပြီဆိုတော့ ဒီ lab လေးကို ဒီမှာပဲ အဆုံးသတ်ချင်ပါတယ်။ ကိုယ်တိုင်လဲ စမ်းလုပ်ကြည့်လို့ရပါတယ်။ အားလုံးပဲ အချိန်ပေးပြီး ဖတ်ရှုပေးတဲ့အတွက်လဲ ကျေးဇူးတင်ပါတယ် ခင်ဗျ။

Author By PoneMyat

ပထမဆုံး အနေနဲ့ ကျွန်တော်ရဲ့ wsl linux လေးတွေ ဘယ်နှစ်ခု ရှိနေလဲဆိုတာကို စစ်ကြည့်ဖို့အတွက်

wsl -l

ဆိုတဲ့ command ကို အသုံးပြုပါမယ်။

wsl -l ဆိုပြီး စစ်လိုက်တာနဲ့ ကျွန်တော်တို့ wsl linux တွေကျလာမည်ဖြစ်ပြီးတော့ ကျွန်တော့်စက်ထဲမှာတော့ Ubuntu နဲ့ AlmaLinuxOS-9 ဆိုတဲ့ wsl linux လေး ၂ခု ရှိနေပါတယ်။ အဲ့ဒီထဲကမှ ကျွန်တော်က AlmaLinuxOS-9 ဆိုတဲ့ wsl လေးကို backup ထုတ်မှာပဲဖြစ်ပါတယ်။ backup ထုတ်မယ်ဆိုရင် အသုံးပြုရမည့် command ကတော့

wsl --export (distribution) (file path)

ပဲဖြစ်ပါတယ်။ distribution နေရာမှာ ကျွန်တော်တို့ backup လုပ်ချင်တဲ့ distribution name ကိုထည့်ရမှာဖြစ်ပြီးတော့ file path ကတော့ backup file သိမ်းမယ့် လမ်းကြောင်းကိုထည့်ခိုင်းတာဖြစ်ပါတယ်။

wsl --export AlmaLinuxOS-9 "D:\wsl\almalinux.tar"

အိုကေဒါဆို AlmaLinuxOS-9 လေးကို backup လုပ်သွားမည်ဖြစ်ပါသည်။

backup လုပ်ပြီးသွားရင်တော့ ပုံပါအတိုင်း the operation completed successfully ပြမည်ဖြစ်ပါသည်။ backup လဲလုပ်ပြီးသွားပြီဆိုတော့ AlmaLinuxOS-9 ဆိုတဲ့ wsl လေးကို unregister လုပ်လိုက်ပါမယ်။

unregister successfully ဖြစ်သွားပြီဆိုတော့အရင်ဆုံး wsl လေးကို အရင်ဆုံးဖွင့်ကြည့်လိုက်ပါမယ်။

ဒါပေမယ့် ဖွင့်လိုက်တဲ့ အချိန်မှာ wsl linux လေးမှာ unregister လုပ်ထားပြီဖြစ်တဲ့အတွက်ကြောင့် အသုံးပြုလို့ရတော့မှာ မဟုတ်တော့ပါဘူး။ အိုကေဒါဆို ကျွန်တော်တို့ wsl backup file အရင်ဆုံးသွား check လိုက်ပါမယ်။

ကျွန်တော်တို့ backup လုပ်ခဲ့တဲ့ wsl လေး ရှိတယ်ဆိုတော့ ပြန်ပြီးတော့အသုံးပြုလို့ရအောင် restore ပြန်လုပ်ပါမယ်။ restore ပြန်လုပ်ရမယ့် command ကတော့

wsl --import (Distribution) (Install Location) (File Path)

wsl linux လေးကို restore ပြန်လုပ်မယ့် အချိန်မှာတော့ install location ဆိုတယ့် လမ်းကြောင်းလေး တစ်ခုတိုးလာပဲဖြစ်ပါတယ်။ အဲ့ဒါကတော့ ကျွန်တော်တို့ wsl linux လေးကို restore လုပ်သည့် အခါ install location သတ်မှတ်ထားသည့် directory မှာ ပြန် restore လုပ်သွားမှာပဲဖြစ်ပါတယ်။ အရင်ဆုံးအနေနဲ့ ကျွန်တော်က C Partition ထဲမှာ WSL ဆိုပြီး အရင်ဆုံး directory ဆောက်လိုက်ပါမယ်။ လမ်းကြောင်းကတော့ "C:\WSL" ဒီအတိုင်းပေါ့။ အိုကေ ဒါဆို directory ဆောက်ပြီးသွားပြီ ဆိုတော့ ကျွန်တော်တို့ backup လုပ်ထားတဲ့ wsl linux ကို restore ပြန်လုပ်တော့မှာပဲ ဖြစ်ပါတယ်။

wsl --import AlmaLinuxOS-9 "C:\WSL" "D:\wsl\almalinux.tar"

ဆိုပြီးတော့ restore ပြန်လုပ်လိုက်ပါမယ်။

restore လုပ်တဲ့အချိန်ကတော့ မိမိရဲ့ wsl file size ပေါ်မူတည်ပြီးတော့ အချိန်ကြာမှာဖြစ်ပါတယ်။ restore ပြီးသွားရင် The operation completed successfully ပြမည်ဖြစ်ပါသည်။ ဒါဆိုရင်တော့ restore လုပ်သွားပြီဖြစ်သည့် အတွက် ကျွန်တော် AlmaLinuxOS-9 wsl လေးကို ပြန်ဖွင့်ကြည့်လိုက်ရအောင်။

အခုဆိုရင်တော့ ကျွန်တော်တို့ AlmaLinuxOS-9 wsl လေးကပြန်အသုံးလို့ရနေပြီဖြစ်ပြီးတော့ backup မလုပ်ခင်က သေချာအောင် hello.txt ဆိုတဲ့ file လေးဆောက်ခဲ့ပြီးမှ backup လုပ်ခဲ့တာဖြစ်ပြီးတော့ restore လုပ်သည့်အခါမှာ hello.txt ဆိုတယ့် file လေးပါပြန်ပါလာတာပဲဖြစ်ပါသည်။ ဒါကတော့ data ပြန်ရတယ်ဆိုတာကို စမ်းပြထားခြင်းပဲဖြစ်ပါတယ်။

အိုကေ ဒါဆိုရင်တော့ wsl တွေပျက်သွားတိုင်း အစကနေ config တွေပြန်ချစရာမလိုအောင် ဒီလိုမျိုး backup သိမ်းထားသင့်တယ် ဆိုတာကို ပြောပြရင်း ဒီ lab လေးကို ဒီမှာပဲ အဆုံးသတ်ချင်ပါတယ်။ အားလုံးပဲ အချိန်ပေးပြီး ဖတ်ရှုပေးတဲ့အတွက်လဲ ကျေးဇူးတင်ပါတယ် ခင်ဗျ။

CentOS မှ Red Hat Enterprise Linux (RHEL) သို့ Migratingလုပ်ခြင်းသည် အများအပြား အကျိုးကျေးဇူးများကို ပေးစွမ်းနိုင်ပါသည်။ အောက်ပါအချက်များသည် RHEL သို့ Migratingလုပ်ခြင်း၏ အဓိက အကျိုးကျေးဇူးများဖြစ်ပါသည်။

1. Official Support and Assurance
   RHEL သည် Red Hat မှ official support and assurance ကို ပေးသည်။ critical situations များတွင် အချိန်မရွေး professional help ရရှိနိုင်ခြင်းကြောင့် system stability and security ကို မြှင့်တင်ပေးသည်။

2. Enhanced Security
   RHEL သည် advanced security features and technologies များကို ပံ့ပိုးပေးသည်။ security vulnerabilities အတွက် အရေးကြီးသောupdates and patches များကို အချိန်မီရရှိနိုင်သည်။

3. High Performance
   RHEL သည် high performance system တစ်ခုဖြစ်ပြီး, robust capabilities and efficiency ကို ပံ့ပိုးပေးသည်။ အထူးသဖြင့်, reliable and powerful systems များ လိုအပ်သည့် large enterprises and organizations များအတွက် သင့်တော်သည်။

4. Advanced Technologies
   RHEL သည် the latest technologies and innovations support ပေးသည်။ ၎င်းသည် သင့် system’s capabilities ကို မြှင့်တင်ရန်အတွက် နောက်ဆုံးပေါ် tools and features များကို အသုံးချနိုင်စေပါသည်။

5. Superior Management
   RHEL သည် system management အတွက် advanced management tools and technologies များကို ပံ့ပိုးပေးသည့် အတွက် system management ကို လွယ်ကူစွာ ပြုလုပ်နိုင်သည်။၎င်းတွင် monitoring, automation, and configuration management အတွက် tools များ ပါဝင်သည်။

6. Scalability and Flexibility
   RHEL သည် highly scalable and flexible ဖြစ်သောကြောင့် အမျိုးမျိုးသော workloads and environments များတွင် လွယ်ကူစွာ လိုက်လျောညီထွေဖြစ်စေပါသည်။ ၎င်းသည် ကြီးထွားလာသော businesses and dynamic IT landscapes များအတွက် အကောင်းဆုံး ရွေးချယ်မှုတစ်ခု ဖြစ်စေပါသည်။

   CentOS မှ RHEL သို့ migrating လုပ်ခြင်းသည် official support, enhanced security, high performance, advanced technologies, superior management, scalability များအတွက် အကျိုးကျေးဇူးများကို ပေးစွမ်းနိုင်သည်။ ဒီအကျိုးကျေးဇူးများကြောင့် RHEL သို့ migration လုပ်ခြင်းသည် မည်သည့် enterprise အတွက်မဆို ဆွဲဆောင်မှုရှိသော ရွေးချယ်မှုတစ်ခုဖြစ်စေသည်။

   Introduction

   CentOS မှ Red Hat Enterprise Linux (RHEL) သို့ Migrating လုပ်ခြင်းသည် ရှုပ်ထွေးနိုင်ပါသည်။ သို့သော် Convert2RHEL utility tool ကို အသုံးပြုခြင်းဖြင့် လုပ်ငန်းစဉ်ကို လွယ်ကူစေသည်။ ယင်း tool သည် RHEL-like distributions များမှ officially supported ထားသော RHEL instances များဆီသို့ ချောမွေ့စွာ Migrating နိုင်စေပြီး သင့်ရဲ့ customizations, configurations, နှင့် workloads များကို ထိန်းသိမ်းထားကြောင်း သေချာစေပါသည်။

   Convert2RHEL သည် Red Hat မှ supported သော tool တစ်ခုဖြစ်ပြီး Migrating လုပ်စဉ်အတွင်း ပြဿနာတစ်စုံတစ်ရာ ကြုံတွေ့ပါက Red Hat Support မှ ဆက်သွယ် အကူအညီတောင်းနိုင်ပါသည်။ RHEL installation/Migration process မစခင်မှာ သင့် CentOS Linux system ကို up-to-date ဖြစ်ကြောင်း သေချာစေရန် လိုအပ်ပါသည်။

Step 1 : Verifying Your CentOS Version

Migrating မလုပ်ဆောင်မီ သင်၏ CentOS Version သည် နောက်ဆုံးထွက်ထားသည့် Version ဖြစ်ကြောင်း အတည်ပြုရန်လိုအပ်ပါသည်။

cat /etc/centos-release

ထွက်လာမည့် output သည် အောက်ပါအတိုင်း ဖြစ်ပါသည်။

CentOS Linux release 7.9.2009 (Core)

Step 2 : Enabling the Convert2RHEL Repository

Convert2RHEL သည် Red Hat က ထုတ်ဝေသည့် package တစ်ခုဖြစ်ပြီး Red Hat CDN မှ download ပြုလုပ်နိုင်ပါသည်။ သင်၏ CentOS server သည် Red Hat CDN နှင့် subscribed မရှိသေးပါက Convert2RHEL repository ကို အရင်ဆုံး enable လုပ်ရန်လိုအပ်ပါသည်။

Step 2.1 : Pull Down the GPG Signing Key

GPG key ကို download လုပ်ရန် အောက်ပါ command ကို အသုံးပြုပါ။

curl -o /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release https://www.redhat.com/security/data/fd431d51.txt

# curl -o /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release https://www.redhat.com/security/data/fd431d51.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1855  100  1855    0     0   2324      0 --:--:-- --:--:-- --:--:--  2324

Step 2.2 : Download the SSL Certificate

SSL certificate ကို download လုပ်ပြီး connection ကို လုံခြုံစေရန် အောက်ပါ command ကို အသုံးပြုပါ။

curl --create-dirs -o /etc/rhsm/ca/redhat-uep.pem https://ftp.redhat.com/redhat/convert2rhel/redhat-uep.pem

# curl --create-dirs -o /etc/rhsm/ca/redhat-uep.pem https://ftp.redhat.com/redhat/convert2rhel/redhat-uep.pem
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  7411  100  7411    0     0  15260      0 --:--:-- --:--:-- --:--:-- 15280

Step 2.3 : Download the Convert2RHEL Repository File

Convert2RHEL repository ကို server တွင် ထည့်သွင်းရန် အောက်ပါ command ကို အသုံးပြုပါ။

curl -o /etc/yum.repos.d/convert2rhel.repo https://ftp.redhat.com/redhat/convert2rhel/7/convert2rhel.repo

# curl -o /etc/yum.repos.d/convert2rhel.repo https://ftp.redhat.com/redhat/convert2rhel/7/convert2rhel.repo
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   247  100   247    0     0    509

Step 3 : Installing Convert2RHEL

Repository ကို enabled လုပ်ပြီးသည့်အခါ Convert2RHEL utility ကို install လုပ်နိုင်ပါပြီ။ယခင်အဆင့်တွင် သင်သည် Convert2RHEL software repository ကို enabled လုပ်ထားသည်။ ၎င်းသည် သင်၏ CentOS Linux server အား convert2rhel RPM packages နှင့် Red Hat CDN မှ ၎င်း၏ dependencies များကို အသုံးပြုနိုင်စေခဲ့သည်။ Convert2RHEL repo ကို enabled လုပ်ထားကြောင်းစစ်ဆေးပါ-

Step 3.1 : Verify the Repository

Convert2RHEL repository ကို enabled ဖြစ်ကြောင်း စစ်ဆေးရန် အောက်ပါ command ကို အသုံးပြုပါ။

yum repolist

# yum repolist
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.pasteur.fr
 * extras: centos.mirror.ate.info
 * updates: ftp.pasteur.fr
repo id                                                                                   repo name                                                                          status
base/7/x86_64                                                                             CentOS-7 - Base                                                                    10,072
convert2rhel-for-rhel-7-rpms                                                              Convert2RHEL for OS 7                                                                   5
extras/7/x86_64                                                                           CentOS-7 - Extras                                                                     512
updates/7/x86_64                                                                          CentOS-7 - Updates                                                                  4,053
repolist: 14,642

Step 3.2 : Install the Convert2RHEL Utility

Convert2RHEL ကို အောက်ပါအတိုင်း Install လုပ်ပါ။

yum install -y convert2rhel

# yum install -y convert2rhel
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.pasteur.fr
 * extras: centos.mirror.ate.info
 * updates: ftp.pasteur.fr
Resolving Dependencies
--> Running transaction check

... output truncated ...

Installed:
  convert2rhel.noarch 0:0.26-1.el7

Dependency Installed:
  libxml2-python.x86_64 0:2.9.1-6.el7_9.6  pexpect.noarch 0:2.3-11.el7             python-backports.x86_64 0:1.0-8.el7  python-backports-ssl_match_hostname.noarch 0:3.5.0.1-1.el7
  python-chardet.noarch 0:2.2.1-3.el7      python-ipaddress.noarch 0:1.0.16-2.el7  python-kitchen.noarch 0:1.1.1-5.el7  python-setuptools.noarch 0:0.9.8-7.el7
  python-six.noarch 0:1.9.0-2.el7          yum-utils.noarch 0:1.1.31-54.el7_8

Complete!

Convert2RHEL Install လုပ်ပြီးပါက Migrating Process ကို ဆက်လက်ဆောင်ရွက်နိုင်ပါပြီ။

Step 4 : Pre-Conversion Analysis

Understanding the Convert2RHEL command

Conversion process ကို အကောင်အထည်ဖော်ရန် အသုံးပြုနိုင်သော arguments များစွာ ရှိသည်။ အဓိကအချက်မှာ သင်၏ new RHEL system ကို active subscription တစ်ခုနှင့် တွဲဖက်registering လုပ်ခြင်း ဖြစ်သည်။ သင့်အနေဖြင့် ရွေးချယ်နိုင်သော နည်းလမ်းများမှာ:

1. Fully interactive session: Conversion ၏ အစိတ်အပိုင်းတစ်ခုအဖြစ် မေးခွန်းများကို ဖြေဆိုခြင်းနှင့် username နှင့် password ကို ထည့်သွင်းရန် လိုအပ်သည်။

2. convert2rhel command အတွင်း username နှင့် password ကို ထည့်သွင်းခြင်း။ ၎င်းသည် သင်၏ Red Hat customer portal အတွက် credentials များကို server ၏ Bash history တွင် plain text အဖြစ် သိမ်းဆည်းထားရန်ဖြစ်သောကြောင့် ကောင်းမွန်သော နည်းလမ်း မဟုတ်ပါ။

3. command ၏ အစိတ်အပိုင်းတစ်ခုအဖြစ် သင့် Organization ID နှင့် Activation Key ကို ထည့်သွင်းခြင်း။ ၎င်းသည် more secure ဖြစ်တယ် သင့် org-id ကို ရှာဖွေပါ၊ activation key ကို ဖန်တီးပါ။

Step 4.1 : Running the Convert2RHEL analyze utility

Conversion ကို automate လုပ်ရန် အောက်ပါ command ကို အသုံးပြုပါ။

convert2rhel --org < ORG ID > --activationkey  < KEY >

ဤလုပ်ငန်းစဉ်ကို automated ဖြစ်စေရန်အတွက်၊ အပေါ်တွင်ဖော်ပြထားသော နံပါတ် 3 မှ activation key combination ကို အသုံးပြုပြီး conversion analysis ကို စတင်မည်ဖြစ်သည်။

convert2rhel analyze --org 12451665 --activationkey convert2rhel

Note: This process will take some time!

# convert2rhel analyze --org 12451665 --activationkey convert2rhel -y

[07/22/2022 18:40:54] TASK - [Prepare: Show Red Hat software EULA] ******************************
The following text is a copy of the November 18, 2019 version of Red Hat GPLv2-Based End User License Agreement (EULA) [1].
For up-to-date version of the EULA, visit [2].
[1] https://www.redhat.com/licenses/Red_Hat_GPLv2-Based_EULA_20191118.pdf
[2] https://www.redhat.com/en/about/agreements

... output truncated ...

Package                                                  Vendor/Packager  Repository
-------                                                  ---------------  ----------
epel-release-7-14.noarch                                 Fedora Project   /epel-release-latest-7.noarch
google-compute-engine-oslogin-20220714.00-g1.el7.x86_64  N/A              google-compute-engine
google-guest-agent-20220713.00-g1.el7.x86_64             N/A              google-compute-engine
google-compute-engine-20220211.00-g1.el7.noarch          N/A              google-compute-engine
gce-disk-expand-20200716.00-g1.el7.x86_64                N/A              google-compute-engine
google-osconfig-agent-20220711.00-g1.el7.x86_64          N/A              google-compute-engine
google-cloud-sdk-396.0.0-1.x86_64                        N/A              google-cloud-sdk

Process ကို ဆက်လက်လုပ်ဆောင်ရန် y ရိုက်ထည့်ပြီး enter နှိပ်ပါ။

Step 4.2 : Reviewing the analysis

Outdated/Invalid kernel ကဲ့သို့သော error များကို တွေ့ရှိပါက၊ Convert2RHEL tool သည် ပြန်လည်ပြင်ဆင်ခြင်း steps များကို ပေးပါလိမ့်မည်။ ဥပမာအားဖြင့်၊ သင်သည် kernel ဗားရှင်းမတူညီမှုကို ကြုံတွေ့ရပါက၊

========== Error (Must fix before conversion) ==========
(ERROR) IS_LOADED_KERNEL_LATEST::INVALID_KERNEL_VERSION - Invalid kernel version detected
     Description: The loaded kernel version mismatch the latest one available in the enabled system repositories
     Diagnosis: The version of the loaded kernel is different from the latest version in the enabled system repositories.
     Latest kernel version available in updates: 3.10.0-1160.108.1.el7
     Loaded kernel version: 3.10.0-1160.102.1.el7
     Remediation: To proceed with the conversion, update the kernel version by executing the following step:

    1. yum install kernel-3.10.0-1160.108.1.el7 -y
    2. reboot

ဤပြဿနာကို ပြန်လည်ဖြေရှင်းရန်၊ အောက်ပါ command ကိုရိုက်ထည့်ပါ။

yum update -y && reboot

Step 5 : Running Convert2RHEL

ယခုသင် inhibitor ကို fixed လုပ်ပြီးသည်နှင့်သင်၏ system ကို RHEL သို့ပြောင်းမည်ဖြစ်သည်။

Step 5.1 : Running the conversion

convert2rhel --org 12451665 --activationkey convert2rhel -y

... output truncated ...

[07/22/2022 18:42:43] TASK - [Convert: Final system checks before main conversion] **************
Comparing the loaded kernel modules with the modules available in the following RHEL kernel packages available in the enabled repositories:

... output truncated ...

[07/22/2022 18:48:33] TASK - [Final: Remove temporary folder /var/lib/convert2rhel/] ************
Temporary folder /var/lib/convert2rhel/ removed

Conversion successful!

WARNING - In order to boot the RHEL kernel, restart of the system is needed.

Conversion ပြီးမြောက်ရန် 15 မိနစ်ခန့် ကြာနိုင်သည်။အပြောင်းအလဲများကို effect ဖြစ်စေရန် သင်သည် system အား reboot လုပ်ရန် လိုအပ်မည်ဖြစ်ပါသည်။

reboot

convert2rhel utility ကို run ခြင်းဖြင့်၊ System သည် ယခု CentOS signed packages များကို Red Hat signed versions များဖြင့် အစားထိုးပါမည်။ System ည် အချိန်အနည်းငယ် Reboot ပါမည်-

1: first time - ဤအပြောင်းအလဲများပြုလုပ်ရန် temporary environment သို့ boot စတင်

2: second time - SELinux contexts များပေါ်တွင် relabel ထည့်သွင်းရန်

3: final time - အသစ်ဖန်တီးထားသော RHEL environment သို့ boot စတင်

Step 6 : Verifying the upgrade

ယခု သင်သည် သင်၏ New RHEL System သို့ ချိတ်ဆက်ထားပြီး၊ အောက်ပါ command ဖြင့် အတည်ပြုပါ။

cat /etc/redhat-release

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.9 (Maipo)

လိုအပ်သော Red Hat repositories များကို enabled လုပ်ထားကြောင်း စစ်ဆေးပါ။ ထို့အပြင်၊ Old CentOS repos များကို မရရှိနိုင်ကြောင်း သတိပြုပါ။

yum repolist

[root@centos ~]# yum repolist
Loaded plugins: fastestmirror, product-id, search-disabled-repos, subscription-manager
Loading mirror speeds from cached hostfile
repo id                                                            repo name                                                                  status
convert2rhel-for-rhel-7-rpms                                       Convert2RHEL for OS 7                                                          10
rhel-7-server-rpms/7Server/x86_64                                  Red Hat Enterprise Linux 7 Server (RPMs)                                   33,833
repolist: 33,843

ယခု သင်သည် Conversion မှ Logs များကို ပြန်လည် review လုပ်နိုင်သည်။

less /var/log/convert2rhel/convert2rhel.log

# less /var/log/convert2rhel/convert2rhel.log

[07/22/2022 17:55:00] TASK - [Prepare: Show Red Hat software EULA] ******************************
The following text is a copy of the November 18, 2019 version of Red Hat GPLv2-Based End User License Agreement (EULA) [1].
For up-to-date version of the EULA, visit [2].
[1] https://www.redhat.com/licenses/Red_Hat_GPLv2-Based_EULA_20191118.pdf
[2] https://www.redhat.com/en/about/agreements

... output truncated ...

Tag - #Linux, #RHEL, #CentOS, #Migration

My Linkedin Profile - https://www.linkedin.com/in/kyaw-thet-htun/

Thank You For Watching

ssh web01

ဆိုပြီးတော့ command prompt မှာ ရိုက်လိုက်တာနဲ့ linux server ထဲကို password မတောင်းပဲ တစ်ခါတည်း login ဝင်သွားအောင် setup လုပ်မှာဖြစ်ပါတယ်။ ဒီလိုအသုံးပြုခြင်းဖြင့် ကျွန်တော်တို့ server တွေထဲကို login ဝင်တဲ့ အခါမှာ ပိုမိုမြန်ဆန်ပြီးတော့ ကိုယ့် Server ရဲ့ ip address တွေကိုလဲ အပေါ်ယံအနေဖြင့် မသိနိုင်တော့ဘူးပေါ့။ ဆိုတော့ စလိုက်ကြရအောင်။

ကျွန်တော်တို့ linux server တွေထဲကို ပုံမှန်အတိုင်း login ဝင်တဲ့အခါမျိုးမှာ command prompt ကနေ

ssh redhat@192.168.109.136

ဆိုပြီးတော့ username ရယ် server ip ရယ်ရိုက်ထည့်လိုက်တာနဲ့ password ရိုက်ထည့်ခိုင်းမှာဖြစ်ပြီး password မှန်ရင်တော့ server ထဲကို login ဝင်သွားမည်ပဲဖြစ်ပါတယ်။ ဒီလိုအသုံးပြုခြင်းက server တစ်လုံးနှစ်လုံးဆို အဆင်ပြေပေမယ့် များစွာသော server တွေကို login ဝင်ရမယ့်အချိန်မှာ အဲ့လိုမျိုး အများကြီးထိုင်ရိုက်နေရတော့မယ်ဆိုရင် အဆင်ပြေမှာမဟုတ်တော့ပါဘူး။ အဲ့လိုမျိုးအခြေအနေမျိုးမှာ MobaXterm လိုမျိုး 3rd party software တွေ သုံးပြီး မိမိဝင်ချင်တယ့် server တွေကို တစ်ခါတည်း add ထားလို့ရပါတယ်။ ကျွန်တော်ကတော့ 3rd party software မသုံးပဲ Windows ရဲ့ command prompt ပဲအသုံးပြုပြီး setup လုပ်သွားမှာဖြစ်ပါတယ်။

First Step - ပထမဆုံးအနေနဲ့ ဘာအရင်လုပ်ရမလဲ ဆိုတော့ ကျွန်တော်တို့ အသုံးပြုနေတယ့် Windows မှာ ssh key ကို အရင်ဆုံး generate ထုတ်ရပါတယ်။ ဆိုတော့ command prompt ကိုဖွင့်ပြီး ssh-keygen ကိုပြီး ရိုက်ပါမယ်။

ssh-keygen ရိုက်လိုက်တာနဲ့ generate ကိုထုတ်မယ့် file လမ်းကြောင်းလာပြပေးမှာဖြစ်ပြီးတော့ default အတိုင်းမလိုချင်ရင်တော့ ကိုယ်ဘာကို custom ပြန်ရေးပြီး ထုတ်လို့ရပါတယ်။ ကျွန်တော်ကတော့ ဒီမှာ လက်ရှိ directory အောက်မှာပဲ lab_key ဆိုပြီးတော့ထုတ်လိုက်ပါတယ်။

ထုတ်ပြီးသွားပီဆိုတော့ လက်ရှိ directory အောက်မှာ lab_key နဲ့ lab_key.pub ဆိုပြီး file လေးနှစ်ခု ရနေပါပီ။ အဲ့ဒီ file လေး နှစ်ဖိုင်ထဲကမှ ကျွန်တော်တို့ login ဝင်ချင်တဲ့ linux server ထဲကို public key file လေးကို copy ကူးပါမယ်။ scp ဆိုသည့် command ကိုအသုံးပြုပြီး windows command prompt ကိုပဲအသုံးပြုသွားပါမယ်။

scp lab_key.pub redhat@192.168.109.136:/home/redhat/.ssh/authorized_keys

ဒီလိုရိုက်လိုက်တာနဲ့ password ရိုက်ခိုင်းမည်ဖြစ်ပြီး server ရဲ့ redhat user ရဲ့ password ရိုက်ပေးရမည်ဖြစ်ပါသည်။

ပုံပါအတိုင်း server ထဲကို lab_key.pub ဆိုသည့် file ကို copy ကူးပြီးသွားပြီဖြစ်ပါသည်။ ဒါဆိုရင်တော့ server ထဲကို password မလိုပဲ login ဝင်လို့ရပြီဖြစ်ပါသည်။ အသုံးပြုသည့် command ကတော့

ssh -i lab_key redhat@192.168.109.136

ဒီလိုဆိုရင်တော့ server ထဲကို password မတောင်းပဲ login ဝင်သွားမှာပဲဖြစ်ပါတယ်။

ကျွန်တော်တို့ထပ်ပြီး လုပ်ချင်တာက server ရဲ့ username နဲ့ ip address ကြီးကို မရိုက်ချင်တာဆိုတော့ နောက်ထပ် ထပ်ပြီးတော့ လုပ်ဆောင်ပေးရမှာရှိပါတယ်။

C:\Users\user_name\.ssh\ ထဲမှာ Config ဆိုပြီးတော့ file လေး တစ်ဖိုင်ကို သွားဆောက်ပါမယ်။ file ဆောက်ပြီးပြီဆိုရင်တော့ အဲ့ ဖိုင်လေးကို ဖွင့်ပြီးတော့ ssh config လေးတွေရေးပါမယ်။

Host web01
  HostName 192.168.109.136
  User redhat

အဲ့ဒီ file လေးထဲမှာ အခုလိုမျိုး ရေးလိုက်ပါမယ်။ Host ကတော့ ကျွန်တော်ကတော့ ssh နဲ့ login ဝင်ရင် ကိုယ်အသုံးပြုချင်သည့် name ကို ထည့်ပေးရမည်ဖြစ်ပြီး , HostName မှာတော့ Server IP , User မှာတော့ သူ့ username ထည့်ပေးရပါမယ်။ ဒါဆိုရင် ကျွန်တော်တို့အသုံးပြုချင်သည့် ပုံစံအတိုင်းရပီပဲ ဖြစ်ပါသည်။

ssh -i lab_key web01

ဒါဆိုရင် ပထမကလို အရှည်ကြီး ရိုက်စရာမလိုတော့ပဲ name လေးပဲရိုက်လိုက်တာနဲ့ server ထဲ login ဝင်သွားပီပဲဖြစ်ပါသည်။

ssh အနောက်က -i ဆိုတဲ့ options ကိုသုံးနေရခြင်းကတော့ ကျွန်တော်တို့က ssh key generate file ကို သူရဲ့ default key name ကိုမသုံးထားလို့ ရိုက်နေရခြင်းပြဖြစ်ပါတယ်။ key-gen ထုတ်တဲ့နေရာမှာ default အတိုင်းပဲထားခဲ့မယ် ဆိုရင် -i options သုံးစရာမလိုပဲ ssh web01 ဆိုပြီးပဲ အသုံးပြုလို့ရမည်ပဲဖြစ်ပါသည်။