1.初始化
git init .
2.增加檔案
git add 檔名
3.紀錄修改內容
git commit -m "描述"
2021年8月19日 星期四
Samba新增使用者指令
useradd "username" # 系統上新增使用者
pdbedit -a -u "username" #新增Samba使用者
smbpasswd "username" #設定Samba使用者密碼
pdbedit -L #列出Samba使用者
2021年4月20日 星期二
2021年4月1日 星期四
2021年3月26日 星期五
windows7啟動資料夾位置
視窗+R然後輸入shell:startup
就可以快速跳到啟動資料夾了
官方寫windows10
實測windows7也適用
參考MS官網
https://support.microsoft.com/zh-tw/windows/%E6%96%B0%E5%A2%9E%E7%9A%84%E6%87%89%E7%94%A8%E7%A8%8B%E5%BC%8F%E4%BB%A5%E5%9C%A8-windows-10-%E5%95%9F%E5%8B%95%E6%99%82%E8%87%AA%E5%8B%95%E5%9F%B7%E8%A1%8C-150da165-dcd9-7230-517b-cf3c295d89dd
2021年3月1日 星期一
Ansible筆記(三)-AD-HOC command及模組的查詢方式
AD-HOC
AD-HOC簡單點說就是在指令行執行Ansible模組的方式
最常用的就是ping這個模組，並且配合ansible.cfg及inventory的內容達到使用目的，為什麼要使用ping模組呢?因為除了交換金鑰外，必需要測試ansible.cfg及inventory的設定是否正常(這是我的習慣啦…)，接續前面的筆記一及二的ansible.cfg及inventory參數設定，使用方式如下：
#ansible -m ping all --將所有inventory中的主機列出來然後樣子會像是下圖的方式
使用格式如下
#ansible -i INVENTORY -m MODULE_NAME -a MODULE_ARGS ...
EX:假設要在serverb新增一個User名稱為"user1"，判斷遠端主機"如果"沒有user1就建立!
#ansible -m user -a 'name=kilin state=persent' serverb.linux.rhce.taipei
*特別注意的部分就是"changed: true"的狀態，這個意思就是說，在執行Ansible的過程如果遠端主沒有被變更狀態，就會顯示為false的狀態，而Ansible會以一些顏色來區分，依照模組的功能判斷，黃色是狀態改變(changed: true)，綠色是沒有被改變(change: false)，紅色是有錯誤訊息或是失敗，藍色是略過(Skip)，以"user"這個模組來說如果遠端主機沒有"user1"的話就會在該主機新增user，當然同樣的ad-hoc指令再執行一次就會顯示為change: false的狀態，意思是有了不再新增。
*Ansible的好處是，如果在執行的過程中發生錯誤，已經改變的就會保留，會中斷在錯誤的地方，後面的模組就不再執行，在Playbook的Debug的上相當方便!
模組的查詢方式
根據上面的範例，user這個模組，我為什麼會知道有name, state的參數可以使用呢?當然不是憑空生出來的啊查詢方式如下
查詢ansible在該版本下支援的的模組(筆記是在2.9.17版(底層是Python2.7.5))
#ansible --version
查詢ansbile支援的模組(ansible-doc)
#ansible-doc -l
查詢"user"這個模組可以如何使用(裡面有說明，不一一解釋)
#ansible-doc user
回到AD-HOC的用途就是可以讓你在指令行執行Ansible佈署，但一次只能用一個模組，如果要執行很多個模組，則需要用到Playbook，Playbook就是一大堆模組組成的AD-HOC，這是一個YAML的檔案格式(請看下方YAML參考網址)，而Yaml格式有個很重要的編寫方式
注意空格!注意空格!注意空格!
因為太重要了要要說三次!!!就用下一篇來充數吧XD
參考網址 >
YAML：https://zh.wikipedia.org/wiki/YAML
https://reurl.cc/L04kKx
又還是以前的筆記…
2021年2月27日 星期六
Kubernetes-操作篇(一)-K8S的Resource
上篇"Kubernetes-架構篇(三)-K8S架構"講到Master及Work node的架構，本篇講到有關Kubernetes的操作部分，Kubernetes簡單點說就是管理Container的工具，會透過一系列的Resource去控制Pods的Life Cycle，而Kubernetes在產生一個Pod時候，會需要一些後面的內容，例如：Registry Images的來源加上自行於Github的程式碼也就是(CI/CD)持續整合及開發，合成之後產生客制的Images，佈署到Kubernetes平台，進而發佈服務給使用者使用。
一般來說K8S在佈署一個Pods時均會使用yaml file的方式進行佈署，裡面定義了這個Pod的Resource Type，(例如pods的resource，service的resource)，這個Pod的名稱，標籤(在K8S的世界中幾乎所有Resource與Pods的連結均是使用這種方式找到各個pod，當然也包括K8S平台所有Nodes之間的溝通)，Images的來源(如果是OCP的話會配合Source to image(S2I)的功能進行佈署)，如果是Service Type的Resource則會是定義暴露的port及Cluster IP、Pod IP(由CNI定義這裡的IP)
Kubernetes的幾個重要的Resource如下：
pods(pod)
Kubernetes執行程式的基本單位(可以有1~N個Containers)，記錄了IP、Persistent storage volumes，例如從Podman上來看跑一個Pod裡面有一個叫XXXX-infra記錄這個Pod的資訊，他是用Kubernetes的pause程式跑起來的一個Container。
Service(svc)
在ip/port上的整合，讓Pod暴露出去可，讓外部主機去連線到Pod中Container的服務，例如httpd開80 port加上Pod的IP再連到cni-podman0 Bridge，最後再Combind到Node上的IP那樣。
Replication Controllers(rc)
簡單點說就是Pods的Cluster，可以管理增加或減少Pods到Nodes上執行，達到Pod的高可用性。
Persistent
Volume(pv)
Pod的永久儲存的空間，來源可以是NFS(+VDO)、Ceph、GFS。Persistent Volume 的功能是負責定義先劃好一個硬碟空間
Persistent
Volume Claims(pvc)
Pod在執行時對Storage的請求，就是在Configure Pod時，這個Pod要多少硬碟容量，跟提交申請單差不多意思啦，PVC會用Tag連結到PV，而PV也會用tag聯結到Pods。
Config
Maps(cm)
如果有些Resource的內容不想讓別人看到，預設是可以看到Resource的內容，這是用來對Resource加密用的一個功能，可以針對User來控制誰可以看，誰不能看。
參考資料 >
Resource type： https://reurl.cc/WERb2L
還有以前學習筆記
Kubernetes-架構篇(三)-K8S的零件
Kubernetes在前面幾篇提到外部介接的部分，透過CRI、CNI、CSI的介面來管理容器，那K8S本身有那些服務呢?其實K8S本身是一個Cluster架構從基本的Single Masters and Multi Node，或是Multi Masters and Multi Nodes，節點中間透過K8S的服務來達到Pacemake及Keepalive的效果，當然因為K8S本身是一個服務管理介面，只是這些偵測及管理程序都是透過Container來完成，不同於以往的服務單一結構，而是透過一些Container的程序構成的基礎服務(例如kube-proxy、kube-api server)組成一個K8S平台服務。
MASTER主機的零件
使用者驗證(Authentication)：
就是利用網頁介面登入做使用者驗證的介面，這點在(OpenShift Container Platform) 上會比較有感覺，(目前因為書讀的太少，在K8S上的驗證還沒有很清楚@@)在K8S或是 OCP會透過API的一個介面進行登入的動作，或是使用一組kubeconfig的驗證檔(是一個 yaml file)，而這個驗證檔則是由X509的方式驗證，會產生一個Oauth Token利用這個Token登入K8S平台進行管理，Token過期則必需要重新產生Token
Etcd(Data Store)：
Etcd是一Master中重要服務之一，他記錄了整個K8S平台的例如：Resource、Container、Cluster的狀態及Configuration，就像是用一個Metadata的方式描述上面的內容長什麼樣子，這些樣子成為一個K8S平台的生態
Kube-apiserver(API+Scheduler)：
kube-apiserver就是管理Pod要到那個節點上執行的服務，配合Controller Manager依系統資源及Pod執行的條件及限制分配到某個Node上執行(像是OpenStack的Nova服務)
Kube-Controller Manager：
是Replication的控制管理的部分，來源是根據etcd記錄的Cluster資訊，當然因為Etcd是個重要的服務，也可以利用Replication的功能來增加etcd的服務，達到Cluster的效果
以上是Master的基礎服務，其中也包含了Registry、Network(SDN)、Image、Auth這些都是以Container的方式進行的服務，這部分除了可以包含在Master上執行外，也可以透過另外的節點執行，稱為Worker Node
Nodes主機
kube-proxy：
其實Master及Node主機都有這個程式，目的是透過kube-apiserver管理service及endpoint的變化，會配合CNI的Network Policy，產生iptables功能的設定，就像前面"Kubernetes-架構篇(一)"提到的那樣(docker-proxy)
kubelet：就是執行Kubernetes的主要服務(Daemon)，包含Master及Node中都會有這個服務
Container Runtime：就是執行Container的工具，每台節點都需要安裝像是Docker(docker engine)、Podman(runC)、CRI-O(crictl)、Containerd
*Router Layer：如果要將Pod的服務暴露在外，就要利過Router layer處理(*此為OCP的部分?)
*Storage：就是儲存Registry的Image或是Container儲存資料的空間，通常會使用NFS來處理
以下是Kubernetes的內部的架構
資料來源 >
架構圖：https://reurl.cc/4yjrmX
kube-proxy：https://reurl.cc/WERxLx
etcd：https://reurl.cc/7y70r9
這是在看文章的過程中想到的補上去...因為之前練習安裝的時候這個會執失敗@@
core-dns：https://reurl.cc/jq3Wqq
2021年2月22日 星期一
Ansible筆記(二)-Inventory
上一篇先說明了ansible.cfg的基本設定還有交換金鑰， 也就是說先定義那個人是這場戲的導演， Inventory就是定義角色的一個設定檔，也就是說有了導演之後，需要找那些人要配合演那個角色(例如：讓某台主機扮成Mariadb Server的角色)，那一群人(主機)要扮演Application Server的角色，均可以自由調整
Inventory的寫法如以下的一些範例：
[Group_name]
192.168.1.30 --單一IP
servera.linux.rhce.taipei --單一Hostname(必需要先在/etc/hosts
serverb.linux.rhce.taipei --或是DNS伺服器上定義)
serverc.linux.rhce.taipei
[other_Group_name]
db[1:9].linux.rhec.taipei --可以是一個範圍的Hostname，例如db1~9.linux.rhce.taipei
10.1.[0:255].[0:255] --可以是一個網段意思就是10.1.0.0/16的意思
192.168.1.[0:255] --就是192.168.1.0/24的意思
server[a:f].linux.rhce.taipei --同第一個是一個範圍的Hostname意思是可以是數字or文字
[dbserver]
db[20:30].linux.rhce.taipei
[apserver]
[services:children] --意思是將上面的dbserver及apserver合併為一個叫services的群組
dbserver --這個群組包含dbserver及apserver
apserver
*Inventory的注意事項
1.在所有Ansible的定義或yaml中，變數或是名稱，如果必需要加上“空格”時，則要用"_"底線當成空格
例如：
取名為db server時中間不能有空格
而是要設定為"db_server"
2.中括弧中的群組名稱不能與“主機名稱(hostname)"相同，當然如果寫了DomainName名稱解析要正確
3.在Playbook中，也就是yaml檔如果要“排除”某個群組中的主機加上單引號及”！“
- name: Deployment "other_Group_name" but not serverc.linux.rhce.taipei and serverf.linux.rhce.taipei
hosts: ' ! serverc.linux.rhce.taipei, serverf.linux.rhce.taipei '
搜尋Inventroy中的Hosts利用ansible指令(拿上面的範例來說好了)，其實可以用vi
列出這個inventory中的所有主機然後配合ansible.cfg設定檔(-v參數)
#anisble -i inventory all --list-hosts -v
列出這個inventory中[other_Group_name]的所有主機
#ansible -i inventory other_Group_name --list-hosts -v
列出這個inventory中的192.168.1.250這台主機
#ansible -i inventory 192.168.1.250 --list-hosts -v
列出這個inventory中的有關linux.rhce.taipei名稱的主機，利用萬用字元" * "
#ansible -i inventroy *.linux.rhce.taipei --list-hosts -v
參考資料 >
還是以前讀書的筆記
2021年2月21日 星期日
Ansible筆記(一)-環境建立
Ansible是一個自動化大量佈署的軟體， 它不用另外在被佈署的主機上安裝Agent端程式，只要在發送端安裝Ansible程式即可，在CentOS 7如果要用Ansible則需要另外安裝Epel-release(目前在7版上的Ansible支援到2.9版)
Ansible主要的設定主要是“ansible.cfg"及"inventory"，”*.yaml“，3大設定所組成(以下會用一些範例說明會比較清楚一些)
> ansible.cfg 定義了執行權限，Inventory的路徑
> Inventory 定義了主機的群組
> *.yaml 定義佈署的模組及動作，例如yum模組，就是拿來安裝套件的
也就是說*.yaml就是你的劇本(一堆模組)，Inventory就是你的演員(主機包含主機群組)，ansible.cfg就是定義誰是導演，ansible-playbook(指令)執行劇本的人員！
佈署架構及環境需求
servera -->Ansible發送端
serverb
serverc
1.每一台主機都需要一個可以佈署的系統帳號，例如使用"ansible"這個user並設定密碼
#useradd ansible
#echo "ansible"| passwd --stdin ansible
2.每一台主機都要設定為了安全性問題，需將ansible user加入sudoers權限
#cat << EOF > /etc/sudores.d/ansible
>ansible ALL=(ALL) NOPASSWD: ALL
>EOF
3.由ServerA的ansible這個user交換金鑰給其他被佈署的Server (如果碰到大量主機需要交換金鑰時可以參考這篇文章的做法http://linux.rhce.taipei/2020/08/sshpass-ssh.html)
[servera]# su - ansible
[servera]$ ssh-keygen
[servera]$ ssh-copy-id ansible@serverb;ssh-copy-id ansible@serverc
*以上都可以用for迴圈的方式建立(我懶得寫啦！！)
4.安裝ansible程式
[servera] #yum install -y epel-release;yum install -y ansible
5.開始使用Ansible建立一個佈署資料夾名為ansible-test，Ansible的基本設定檔“ansible.cfg"分別會依下面的順序載入，注意喔這是有順序的！
1. /path/to/your/ansbile.cfg -->自定的ansible.cfg的路徑
2. ./ansible.cfg -->執行Inventory的那個目錄
3. ~/.ansible.cfg -->執行Inventory的User的Home目錄
4. /etc/ansible/ansible.cfg -->預設的cfg目錄
以下為基本的ansible.cfg，意思是最少只需要以下內容即可以處理大部分的Playbook的執行
[servera]$ mkdir ansible-test
[servera]$ cd ansible-test
[servera ansible-test\]$ vi ansible.cfg
[defaults]
inventory = ./inventory --inventory的目錄
remote_user = ansible --就是誰是這場戲的導演，就是每台主機都要有這個user
ask_pass = [ true | flase ] --執行Playbook的過程中是否詢問密碼
[privilege_escalation]
become = [ true | false ] --是否開啟提升權限功能
become_method = sudo --提升權限的方法是用sudo
become_user = root --提升權限後遠端主機變成誰，例如是root
become_ask_pass = [ true | false ] --執行Playbook的過程中是否詢問密碼
資料來源 >
以前讀書的筆記！
Teleport 跳板機
Teleport
What is teleport?
Gravitational Teleport 是用於管理通過SSH或Kubernetes API對Linux服務器群集的訪問的網關。
它用於需要以下用途的組織，而不是傳統的OpenSSH：
* 保護其基礎架構，並遵守安全最佳實踐和法規要求。
* 全面了解整個基礎架構中發生的活動。
* 減少傳統和雲本地基礎架構中特權訪問管理的運營開銷。
Teleport 官網
Teleport 官網文檔
Teleport Installation
Teleport Github
ECMWF tsh
Panther
2021年2月20日 星期六
Kubernetes筆記-架構篇(二)-CNI理解-2
上一篇的"CNI理解-1"講到一些CNI的概念還有長什麼樣子，其實就是用一個設定檔來定義Kubernetes Pod的網路，也就是網路虛擬化的方式之一，這裡會提到一些Kubernetes的零件以及連線的方式內容，K8S零件部分後面會再說明
目前在Kubernetes上較常用常看到的CNI外掛套件程式分別有Flannel、Calico、Weave、Canal，目前自已看過的網路的文章，以及問過會這部分的朋友，比較常用的是Flannel跟Calico兩種CNI外掛，因為目前還在理解中，有些安裝過程及使用上較不熟悉，先從Flannel這個CNI外掛切入Kubernetes的網路來，而Flannel在安裝設定上較為容易上手。
Flannel的安裝在Kubernetes上也是透過yaml定義檔，透過K8S的"deployment"(這是K8S的resource後面會再說明)佈署成flanneld的服務(當然佈署的過程中會包含一些K8S的resource功能例如Configmap、ClusterRole、ClusterRoleBinding之類的內容，操作過後才會比較了解這些resource在幹麼不在這說明)Flannel的架構及連線過程如下圖
透過上圖就可以得知如果K8S在執行Container的時候(請把圖中的docker0改成flannel0這個Bridge)是如何從單一Node主機轉變成為多Nodes主機的架構，每台主機透過Master Node中的etcd加上flanneld的控制讓2台以上的Node可以達到溝通的效果，也就是說如果你要在2台Node上產生10個Pod，這時候Kubernetes就會用Flannel這個CNI外掛產生10個IP(就是上圖中的veth0的IP，想像一下2台主機一共有10個Pod跟10個IP)，當然這個vetn0就是透過Network Namespace產生的結果全部都由各自主機的flannel0這個Bridge類型的網路來管理Pod，當連線進入時會透過Routing Table加上Pod標籤的方式找到特定的Pod。
回過頭來說那Flannel是怎麼去分配各個Node的IP呢?簡單點說就是在利用kubeadm工具安裝K8S時，就要定義--pod-network-cidr=X.X.X.X/X然後K8S就會在各個Node上定義Pod可以用的網路，這些定義檔在
/run/flannel/subnet.env
各個節點執行Pod時會根據上述檔案的定義分配該網路的IP讓Pod得到上網的能力!後面講到安裝的時候會再說明一次
kubeadmin在執行時則是利用kube-controller-manager這個程式控制cidr-network，因為執行的參數很多，重點就是下面3個參數
--cluster-cidr=10.244.0.0/16 -->定義Pod network
--allocate-node-cidrs=true
--node-cidr-mask-size=24 -->定義Pod network的網段
參考資料 >
https://github.com/flannel-io/flannel
https://jimmysong.io/kubernetes-handbook/
https://www.hwchiu.com/cni-flannel-ii.html
2021年2月19日 星期五
Kubernetes筆記-架構篇(二)-CNI理解-1
CNI在架構篇(一)的時候有說明過，其實對Container Runtime的程式而言CNI是一種網路虛擬化的實現，每個CNI都有自已所需要設定的規格。
例如像是Podman，如果要創建一個自已的Pod要用網路(段)，則要利用podman的工具去創建一個網路(段)，如果要在Pod執行時套用自已設定的網路(段)則要另外加上參數才會套用到這個自建的網路。
舉一下例子，podman執行Container時會有一個預設的"cni-podman0"(10.85.0.0/16的網段，執行後會自動建立!)這個cni-podman0對實體主機而言就是一個Bridge類型的網路並且可以接上Pod並分配網IP給Pod，以便讓podman工具可以透過cni-podman0去連線到Pod的內部或是從實體主機透過網頁看到程式服務的內容
當然如果想建立自已的Pod網路(段)如下範例：
建立一個10.1.0.0網段，名稱為mynetwork的podman Bidge
#podman network create --subnet 10.1.0.0/16 mynetwork
此時會在/etc/cni/net.d/下產生一個名稱為mynetwork.conf(或是*.conflist多重網路下使用)的一個json的設定檔，裡面有定義Podman所需要的零件這個零件要參考各自的CNI軟體提供的零件來定義(一開始可以用flannel這個CNI來學習網路架構及理解較為簡單)。
以下是一個CNI Network Config Json檔內容的樣子
當然CNI也可以創建除了Bridge這個類型的網路外，也可創建多種不同類型的例如："ovs"類型的網路，較常見到的就是Bridge類型的網路，也就是說利用"平版"Flat的網路來架構一個虛擬化的網路結構，通常如果沒有殊需求的話，一般來說可以套用CNI預設的網路設定即可。
參考資料 >
https://www.hwchiu.com/cni.html
https://github.com/containernetworking/cni
cni spec: https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md
2021年2月16日 星期二
Kubernetes筆記-架構篇(一)
Kubernetes筆記-架構篇(一)
Kubernetes的外部架構如下
上述架構就是說Kubernetes提供了CNI、CRI、CSI的API介面去跟不同而且符合Open Container Intialtive(OCI)基金會制定的標準介接。
Container Runtime Interface(CRI)
就是常聽到的Docker Engine、Podman(runC)、Containerd、CRI-O(crictl)等執行Container的程式，而Docker因為Kubernetes在1.20以後不支援，其原因是因為Docker在與Kubernetes介接時會再用一個外掛dockershim(由Kubernentes維護)，但因為只要Docker改了，dockershim這層就要再更新，所以為了維持Kubernetes的完整性，所以在1.20就被放棄不維護(意思是在1,19以前其實還是可以用的)
Container Network Interface(CNI)
CNI的用途就是提供Pod上網、分配給Pod IP可以是ipv4、ipv6，利用Kubernetes的介面去管理Network Policy，然後看CNI的工具有沒有支援Kubernetes的功能。這個Network Policy就是限制Pod與Pod之間的網路傳輸，或是點對點之間傳輸(就是沒有IP的Pod啦!)
CNI的Network Policy 的意義就是說當一個Pod在執行的過程中，會準備好一系列的參數執行時套用containerID等資訊，就像是Docker在執行一個Container時，會用一個docker-proxy的工具幫你把防火牆，IP、Container Port與Host Port的對應等資訊套用到Container上面，讓你可以管理Container的內容，只這一段從原來的CRI工具(如crictl podman docker)變成由Kubernetes完成，這就是K8S在Network Policy在上做的事情，所以在跑Container時因為Policy都幫你做好好的，對這段過程就變的淡淡的沒感覺，但其實就是在Host上新增一個可以連到Container的Bridge例如：cni0，然後這些Pod會被CNI的工具例如Flannel去分配IP到Pod上，而K8S可以透過CNI的介面介接例如：docker-proxy的Network Policy的工具，讓Pod有上網及被取存的能力!
Container Storage Interface(CSI)
就是Kubernetes可以支援的Storage介面啦，就是我們常聽到的ceph、NFS…等Storage的功能啦，大部分常用的是NFS Storage，而Kuberneres怎麼使用呢?就是用pv與pvc(這兩個是K8S的resorce之後會說明)來使用Storage的資源
參考網址：
CRI à https://reurl.cc/5o8096
CNI à https://reurl.cc/o9ZOk3
CSI à https://reurl.cc/NXGzVq
訂閱：
意見 (Atom)