騰訊云gitlab（騰訊云服務器）

本文目錄一覽：

• 1、記一次騰訊云服務器換成阿里鏡像源后出問題又換回來
• 2、如何系統地學習Docker？
• 3、數據丟失事故持續發生，有數據備份的的最佳實踐嗎？
• 4、騰訊云負載均衡client_max_body_size配置
• 5、基于Kubernetes的持續部署方案

記一次騰訊云服務器換成阿里鏡像源后出問題又換回來

ubuntu16.4 gitlab從 12.10.0-ee 一步步升級到14.0.0后無法啟動,報錯如下

/opt/gitlab/embedded/bin/ruby: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /opt/gitlab/embedded/lib/libruby.so.2.1)

/opt/gitlab/embedded/bin/ruby: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by /opt/gitlab/embedded/lib/libruby.so.2.1)

降版本也無法降.

換成阿里鏡像源更新成功ruby后,gitlab能正常啟動.

sudo?/etc/apt/sources.list

刪除里面的內容,更換源

deb xenial main

deb-src xenial main

deb xenial-updates main

deb-src xenial-updates main

deb xenial universe

deb-src xenial universe

deb xenial-updates universe

deb-src xenial-updates universe

deb xenial-security main

deb-src xenial-security main

deb xenial-security universe

deb-src xenial-security universe

更新緩存

apt-get clean all

apt-get update

但是gitlib過段時間就不能用,服務器也進不去,騰訊云也不能檢測服務器信息

我把gitlab版本降到13.12.15-ee

然后我又把源換回騰訊的

sudo?/etc/apt/sources.list

Ubuntu 14.04

deb trusty main restricted universe multiverse

deb trusty-updates main restricted universe multiverse

deb trusty-security main restricted universe multiverse

#deb trusty-backports main restricted universe multiverse

#deb trusty-proposed main restricted universe multiverse

deb-src trusty main restricted universe multiverse

deb-src trusty-updates main restricted universe multiverse

deb-src trusty-security main restricted universe multiverse

#deb-src trusty-backports main restricted universe multiverse

#deb-src trusty-proposed main restricted universe multiverse

Ubuntu 16.04

deb xenial main restricted universe multiverse

deb xenial-security main restricted universe multiverse

deb xenial-updates main restricted universe multiverse

#deb xenial-proposed main restricted universe multiverse

#deb xenial-backports main restricted universe multiverse

deb-src xenial main restricted universe multiverse

deb-src xenial-security main restricted universe multiverse

deb-src xenial-updates main restricted universe multiverse

#deb-src xenial-proposed main restricted universe multiverse

#deb-src xenial-backports main restricted universe multiverse

若您使用騰訊云服務器，請將源的域名從 mirrors.cloud.tencent.com 改為 mirrors.tencentyun.com，使用內網流量不占用公網流量。

更新緩存

apt-get clean all

apt-get update

后臺監控正常,服務器穩定了.

如何系統地學習Docker？

1Docker 技術可謂是近年最火熱的技術之一，鋪天蓋地的技術論壇和各種講座，大家都在分享關于如何容器化及如何使用Docker優化自己運維和開發流程的經驗。隨著Docker技術的逐漸普及，使用Docker已經不再是一個難題?，F在更加重要的是生產環境容器化的最佳實踐，另外就是容器的編排框架之爭。但是，對于技術人員來說，除去Docker 外表的繁華外，什么是容器，容器到底是怎么創建的，容器底層的技術探秘也是非常重要的。2014年開始接觸 Docker的時候，經歷了從最初的新奇—感嘆竟然還有Docker 這樣的好工具，到逐漸熟悉Docker的各種功能，嘗試在生產環境中使用Docker技術的過程。但是，每每被人問到：“Docker技術到底是怎么實現的呢”我只能粗粗淺淺地說：“Docker是使用Linux Kernel的Namespace 和 Cgroups實現的一種容器技術?！蹦敲?，什么是Namespace，什么是Cgroups，Docker是怎么使用它們的，容器到底是怎么一步步被創建出來的.問到這些，我就會支支吾吾地不知所以。由此可見，了解容器技術的底層技術，然后明白它們是如何工作的，尤為重要，這些才是整個容器技術的基石，掌握了這些基石才能更加容易地向上攀登。

2從docker的用途上來考慮，看docker能否解決你工作中遇到的問題。例如在實際開發過程中，經常遇到的持續集成問題，軟件開發，測試，部署，如何做成自動化的。配合github Jenkins和docker實現自動化部署，系統持續集成。docker最重要的是編排，如何合理有效穩定的管理各個容器，調度容器?？梢钥纯磌8s，自己動手搭建跑跑看。docker本身并沒有引入新的技術，都是在linux原有的基礎上做的融合?？梢躁P注docker源碼分析。UCloud也支持Docker，推出了UDocker產品。UCloud - 專業云計算服務商。

數據丟失事故持續發生，有數據備份的的最佳實踐嗎？

確實是，意外總是不能避免，但風險能把把控的就是做好數據備份。數據千萬條，備份第一條！你可以用一下UCache災備云平臺的數據備份功能挺多的。

支持各種顆粒大小的數據備份/恢復

一站式完成所有服務器與備份/恢復功能、軟件自動化、自定義模板策略

超強的數據搬遷能力，可達到1GB/S的數據搬遷能力

高安全級別的傳輸加密、存儲加密過程保障數據安全

具體數據備份操作步驟，可參考下面最佳實踐指南：

第一步：在ucache災備云先開通個管理賬號；

第二步：開完賬號他們客服會協助你根據你們服務器使用的操作系統給你一個安裝的客戶端，安裝時綁定你的管理賬號，估計也就幾分鐘。

第三步：在ucache災備云平臺登錄控制臺的管理賬號，進行相應的操作：

1、新建備份任務，如：windows2003操作系統，可以直接把整個磁盤進行勾選做完全備份，500GB的數據我看備份速度后臺顯示可以達到1G/秒，一會兒的功能就完成了一次完全備份，因為這個云災備平臺有壓縮加密碼、自動重刪功能，實際顯示備份容量占用了也就100多個GB，備份速度還挺快的。不同版本的操作系統、不同的版本的數據庫、不同類型的應用文件系統、虛擬化/平臺、NAS都支持，可以無限的添加備份任務，根據你們公司需要備份的應用場景無限添加就可以了，很方便。

2、在控制臺設置定時備份，如設置成：每天晚上10點進行；設備策略，增量備份、永久增量備份，多副本管理等，我對數據庫設置的是實時備份，還可以對備份任務設備流量控制，如這個備份任務我選擇的是5M；還可以設置任務告警，如：某個備份任務失敗郵件提醒我，賬號連續登錄三次錯誤郵件提醒我，等根據自己的要求設置就行。每天還可以查看任務日志，了解企業備份情況。

3、數據恢復這個我試了一下可以直接選擇想要恢復的時間節點，點自動恢復，恢復某部分數據，也可以全部恢復，可以恢復到原路徑，還可以恢復到其它設備上，恢復演練，任務接管功能都有，看企業需要，自己操作即可，功能還挺多的。

云災備這種容災備份方式感覺還可以，挺安全的，對了，里面還可以設備加密類型，有國標的還有256位加密的，這種數據備份操作還挺簡單的，人人可以上手，定時、自動功能也很齊全，算是非常不錯的一個選擇吧。

騰訊云負載均衡client_max_body_size配置

在騰訊云部署gitlab服務器，前置負載均衡配置https。

上傳的時候報錯

配置騰訊云負載均衡個性化配置如下：

基于Kubernetes的持續部署方案

文章轉載自Docker

方案概述

本技術方案為基于Kubernetes為核心的持續部署（下文簡稱CD）方案，可以滿足開發方的程序級日志查看分析，運維方的快速擴容與日常運維分析，并且可以保證用戶的服務體驗。并且整套放在可以在資源利用率上進一步提升，在不降低服務可靠性的前提下降低資源使用成本。

使用場景分析

本方案適用于以Tomcat為容器的JavaWeb項目的持續部署過程，在Kubernetes方案中，所有的Node節點均采用統一配置，根據業務環境的需求進行節點數量的控制。

技術架構與選型

Kubernetes集群部署模式：Stacked etcd topology

Kubernetes的安裝使用kubeadm安裝為高可用集群，并選用Stacked etcd topology 模式。

詳情參考。

Kubernetes生態技術選型：網絡層面選型Weave

容器網絡解決方案。Weave創建的虛擬網絡可以將部署在多個主機上的容器連接起來。對容器來說，Weave就像一個巨大的以太網交換機，所有容器都被接入這個交換機，容器可以直接通信，無需 NAT 和端口映射。

原理詳解：

Kubernetes生態技術選型：對外服務選型NodePort

Kubernetes目前支持NodePort、LoadBanlace、Ingress三種對外提供服務的模式，其中LoadBanlace需要云平臺的支持，阿里云提供了解決方案，但騰訊云未找到，Ingress技術為新出技術。整體評估采用NodePort方式更為靈活，每個服務一個唯一的對外IP地址，并且使用Nginx進行負載均衡（采用Nginx主要為日志分析）。

介紹與使用方法：。

持續部署過程

各組件業務配置

Kubernetes業務配置

命名空間

在業務上，Kubernetes默認配置兩套Namespace，分別為Master存放正式環境，Develop配置測試環境。

對外端口

正式環境Web端口以32001開始，測試環境以31001開始，且一一對應。

Master數據目錄

K8s-Master下的data目錄下為k8s-cd-config， k8s-cd-config目錄存放各業務的yaml配置，二級目錄為域名，三級目錄劃分Master（正式），Develop（測試），目錄下以 版本號-構建ID-GITID.yaml 命名文件，時間最后一個即為當前線上的使用配置文件，為了運維方便，在二級目錄同級內，生成一個軟鏈連接到最新的正式與測試配置文件。注意，k8s-cd-config僅在其中一臺Master中存在。

Node數據目錄

節點下的/data一級目錄下分Filebeat、Dockerlibs、Nodelogs，其中Dockerlibs存放Docker相關數據，Nodelogs目錄通過volume的方式掛載入Kubernetes的Pod， Nodelogs下分Develop與Master目錄，區分正式環境與測試環境，每個Master與Develop下分為accesslogs、devlogs、tomcatlogs分別存放訪問日志，開發部日志，Tomcat日志，日志目錄下為項目（域名），域名下為Pod名稱目錄。

注意事項 ： 節點加入集群后，一定要下載手工下載kubernetes-dashboard-amd64鏡像，防止dashboard所在節點掛掉以后dashboard無法在其他節點啟動。

Harbor業務配置

業務分組

Harbor重定義其Registry的存儲路徑直接使用docker-compose安裝。template 存放基礎進項，各域名分組存放業務鏡像。

鏡像命名

分組下鏡像以站點域名:版本號-類型-CDGITLAB為名稱，并基于版本號確定不同的站點版本。

數據目錄

Harbor數據目錄統一存放在/data下。

備份策略

Harbor默認不設置備份，對于業務鏡像無需進行備份，每次進行構建即可，對于模板類鏡像，在Jenkins機器上均可以找到，若Harbor出現問題，則直接重建，并將Jenkins上的模板鏡像進行重新push。

注意：為了業務的穩定性，Harbor由獨立的服務運行（基于Docker），并不運行在Kubernetes內。

Jenkins業務配置

數據目錄

Jenkins下的data目錄分為dockerlibs、thinbackups、gitlab-files 、jks-cd-config。

Dockerlibs存放Docker相關文件，thinbackups存放每日的Jenkins備份，gitlab-files存放構建GitLab的文件（運維可以在此操作pull，push），jks-cd-config為jks構建目錄。

Jenkins機使用/data/jks-cd-config目錄存放構建內容，二級目錄為域名，三級目錄為版本號（以開發部版本號為準），三級目錄下存放ROOT.war，四級目錄為構建ID_GITID，目錄下存放構建的原始數據。

節點每天進行images清理工作。

業務分組

Jenkins的分組分為template與各domain，template存放模板，domain以域名的形式存放正式項目：

新項目由運維手工創建，后續的秩序構建過程由開發部調用API完成。

構建參數

Jenkins構建時，需要傳遞三參數，1：程序版本號，2：類型：apply與delete，3：正式環境還是測試環境，正式環境為Master，測試環境為Develop，對應Kubernetes的Namespace。

此部分功能后期將通過開發部的構建憑條調用JenkinsAPI實現。

JenkinsAPI

APIDoc：

Token：

備份策略

Jenins安裝ThinBackup插件，配置每小時進行一次全局備份，且最多保留10份，備份后數據傳至異地。

注意：為了業務的穩定性，Jenkins由獨立的服務運行，并不運行在Kubernetes內。

GitLab業務配置

業務分組

CD GitLab項目下分兩個組template與各domain，template存放模板文件。例如：

Git分支

default下以域名劃分項目，每個項目劃分Master與Develop兩個分支，分別存放正式環境與測試環境CD文件。

CD文件樹

備份策略

GitLab使用gitlab-rake gitlab:backup:create進行每日定期備份，并傳送至異地。

EFK與日志管理

Elasticsearch

ES數據通過索引僅保留近10天的數據，每日通過腳本方式進行數據刪除。ES的數據保存在/data/elasticsearch目錄下。

Filebeat

在每個Node節點啟動一個Filebeat進程，用于日志的采集工作，filebeat分別監控：

其中，tomcatlogs日志需要進行特殊處理，進行多行合并，數據寫入ES時，使用processors. Dissect進行目錄名稱截取，并使用域名作為ES的索引使用。

截取gy. wtype ( master或develop) , ltype(accesslogs 、tomcatlogs、devlogs),domain(xxx.gyyx.cn)。

Kibana

Kibana目前我們僅使用其discover節點，用于日志數據的查詢，在配置方面。

Kibana配置使用“域名-*”方式進行配置，每次新增域名，需要在此進行手工配置。

Kibana使用discover查看時，默認展示一個域名下所有的日志，可以通過gy.wtype篩選選擇查看測試環境還是正式環境，或者通過gy.ltype哪種日志類型。

容器資源監控

容器資源使用WeaveScope進行資源消耗監控。

福利

掃描添加我微信，備注“ 姓名+公司職位 ”，加入【 云計算學習交流群 】，和志同道合的朋友們共同打卡學習！

推薦閱讀：

喜歡就點擊“好看”吧

騰訊云gitlab的介紹就聊到這里吧，感謝你花時間閱讀本站內容，更多關于騰訊云服務器、騰訊云gitlab的信息別忘了在企贏網絡進行查找喔。