Authorkilawang

GCP – Stackdriver Logging 解決無法收集log問題

這兩天卡了一個問題

Stackdriver Logging的功能在Basic版本上也是可以使用的

但因為後來發現舊LOG檔案太大

中間停止收集

然後清空,再重新啟動時發現

LOG的收集停止了

 

這時去確認agent的設定檔

找 pos_file的路徑

vi 這個設定檔,會看到目前取得的資料值

把這一行清空,再將agent重啟

LOG的收集就恢復正常了

本來以為是直接爬LOG連續的爬

沒想到還有存進度的值….

 



 

GCP – 費用計算機

在AWS上有很方便的計算成本工具

相對的在GCP也有這樣子的工具

https://cloud.google.com/products/calculator/

使用方式有點與AWS不同

但還是大同小異,有需要的可以使用一下計算成本

再評估是否要使用GCP喔

GCP – 使用Image開機自動替換Hostname

這個問題在AWS上遇過,但是AWS即使使用AMI啟動

也是會替換成IP開頭的hostname

而在GCP上則是會沿用上一次壓成的Image

例如我原本使用 web-01的hostname 壓成Image

在使用這個Image啟動後的server還會是web-01

造成做一個就要連線修改一次

 

這時拿出AWS的經驗,先找出如何呼叫instance的metadata

 

再使用腳本替換掉,寫了一隻shell
#!/bin/bash

name=`curl “http://metadata.google.internal/computeMetadata/v1/instance/name” -H “Metadata-Flavor: Google”`

hostnamectl set-hostname $name

systemctl restart rsyslog.service

再啟動instance時,在開機啟動碼中填入即可

如果有其他的指令需要開機啟動,可以寫成一隻boot.sh

在壓成image時放入,然後再啟動instance時

一樣使用開機啟動碼去執行

例如,開機替換hostname並拉取web 的設定檔等指令

 

我寫完shell之後搭配變數使用,可以下 web 就拉取web設定檔

設定 ap 就拉取 ap設定檔等

減少手動部署時間

 

GCP – Server 加入HTTP 負載平衡

前陣子在修改架構時,要將目前的架構加入HA的概念

所以負載平衡是少不了的,但看了一下教學

都是從頭開始做的,現有的Server要加入有點麻煩

所以自己嘗試了一下,順手就寫一下文章

 

首先在需要加入的Server中,點選新建個體群組

修改名稱,其餘設定不變,在port的命名跟port號填上需要設定的

注意,如果server有分兩個az,則兩台的個體群組需要分開設定

如asia-a有web-01 但 asia-b 有web-02 ,則要設定兩組

預設的個體就會直接被套用進去,之後按建立即可

兩個個體群組都建立完成後

選擇網路服務->負載平衡

選擇HTTP(S)負載平衡,這裡有地方需要注意,如果對外服務port不是80、8080的話,只能使用TCP負載平衡,如8443這種port

名稱設定打上自己需要設定的,之後設定後端server群組,建立後端服務

如果是靜態服務的項目,如圖片檔,可以直接指向Bucket(Cloud Storage)

port不用設定,如果在設定個體群組有設定的時候,選擇個體群組就會跳出顯示

可以直接套用進去

設定可以使用CPU負載或是連線的要求數量去決定,這裡先用預設

之後新增健康檢查

這裡需要注意FW規則需要加入google檢查的IP網段

130.211.0.0/22,35.191.0.0/16 否則會永遠偵測不到存活,因為連不到

預設先用http 80 去get /

這裡有一個問題,如果你的地區有3個az,連續檢查兩次存活的話

那每次監測就是3*2=6次get,如果有一些防禦機制的話要留意

接著主機與路徑規劃不需特別設定,除非有不同的PATH要導向不同的個體群組

如 /web 給後端web群組  /member 給後端會員群組 這樣

 

接著設定前端,IP通常是設定一組,不是設定臨時

PORT只有80、8080可以選

完成後點選建立

就創建好了 

 

GCP – FW規則CLI指令

最近新工作都是使用GCP在環境的建置上

由於摸熟了AWS的規則,切換過來發現GCP的不同

為了快速的新增這些設定,CLI的指令就比較好用

然後一行一行塞又覺得很慢,所以寫偷懶的shell

在專案內啟用google cloud shell

會出現一個shell的視窗

這時就可以執行CLI指令了,但一行一行下太麻煩

所以我用shell的方式執行

vi fw.sh

塞了兩行,如果需要大量產生FW規則的話

就以此類推,例如

#!/bin/bash

a=123.123.123.123
b=111.111.0.0/16
c=111.222.111.111
d=222.222.222.222

 

#設定aIP可以連接
#gcloud compute firewall-rules create allow-proxy-to-b –allow tcp:8080,tcp:8443 –source-ranges=$a –target-tags=allow-a

#開放snmp給c監控
gcloud compute firewall-rules create allow-snmp –allow udp:161 –source-ranges=$c

#開放健康檢查使用
gcloud compute firewall-rules create allow-ha-check –allow all –source-ranges=$b

#開放公司內部IP
gcloud compute firewall-rules create allow-office –allow all –source-ranges=$d –target-tags=office

之後離開

chmod +x fw.sh

sh fw.sh

就可以快速塞FW規則進GCP專案了

AWS – RDS Restore to Point in Time

昨天犯了一個錯誤,用錯腳本,導致更新資料到資料庫時,更新到Production上

原本是要更新到空的Stage資料庫上的…

緊急發現的時候需要還原,但是距離上一次備份資料是前一天

中間的資料差損失會造成很誇張的後果

 

印象中記得AWS有一個Restore to Point in Time的功能

就直接硬著頭皮上了

使用Restore to Point in Time有兩個條件

1.RDS必須有開啟 Automated Backups

2.同上一點,備份的區間就是可以回復的時間區間

舉例:我備份檔案選擇7天,那在選擇還原點的時間就是這七天內都可選

 

確認是不是有開啟很簡單,確認RDS選單內有沒有出現一堆Automated就是了

系統會自動製作許多還原點的Snapshots

還原流程則是

1.選擇你當下需要還原的RDS,在Instance Actions中選擇Restore to Point in Time

 

2.會出現一個建立新RDS的畫面,主要需要留意上方出現的還原時間選擇點

系統會預設最後一筆還原時間,是當下的5分鐘之前

或是你可以選擇在你設定的備份區間之內的任一時間點

 

3.幫還原的RDS設定名稱,其他設定預設會與原本的RDS相同,如VPC、Multi_AZ等

 

4.Launch DB即可

接著將連線導回還原時間點新建立的DB,基本上就完成的還原的動作

我實際使用後檢查DB的時間

我建立是11:27:00的還原點,DB內的最後一筆資料時間為11:26:55

所以還是會有些微的誤差,但比起系統最後一次備份的時間,還是好太多了

提供給各位參考

 

AWS – EC2 快速建立L2TP VPN

最近有接到一個需求,因許多手機不支援PPTP的VPN協定

大多要求更安全的VPN連接方式

所以要建立一個L2TP的VPN,然後要在AWS上建置

 

之前我建立L2TP的時候是在實體Server上做的,基本上都快忘光了

也很懶得從頭一步一步按部就班的去做

只好開始找懶人包,在研究了三小時之後找到一個百分百完美版

https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/README-zh.md

Lin Song (linsongui@gmail.com) 所建立的專案

基本上一鍵可以搞定

 

至於我這邊要補充的就是

PSK 的修改路徑 /etc/ipsec.secrets

LOG的開啟與debug模式修改路經 /etc/ppp/options.xl2tpd

新增帳戶在 /etc/ppp/chap-secrets

大致上是這樣子

 

應該是目前最簡單的安裝方式了

AWS – 線上繪製架構圖平台

今天討論事情才發現到

我沒有提供過任何的架構圖工具

所以補一篇文章提供一下我平常畫AWS架構圖的工具

https://cacoo.com/

免費版本只能輸出PNG

然後在 cacoo store商店內搜尋 AWS

即可找到AWS相關的服務套件

接下來就可以在線上畫架構圖了

另外也有雲端操作記錄的保存

萬一不小心關掉網頁 存檔之前操作記錄還是會留著的

Java Web 另一個選擇 Resin

兩年前曾經碰過的一套Java Web Server

當初是因為總監的要求才去研究,實際摸過之後發現其實效能很好

正常的Java Web 都是 Apache + Tomcat

然後開始有人用 Nginx + Tomcat

最後我是摸到了 Nginx + Resin

如果沒被修改掉的話,Yiabi應該還是我們當初建置的 Nginx + Resin 架構

 

首先官網是 http://caucho.com/

右上角就可以下載,這個是手動編譯版本

下載tar.gz版本之後 解壓縮 進到目錄之後編譯

#/configure –prefix=/usr/local/resin

#修改設定檔

cd /usr/local/resin/conf

vi resin.properties

#註解拿掉

#web_admin_external : true
#port也在此修改
#修改設定vi resin.xml

修改webapp id與路徑

<web-app id=”/Maltese” root-directory=”/home/webuser/ResinJservRoot/Maltese”/>

修改自動deploy路徑設定
web-app-deploy path=”/home/webuser/ResinJservRoot”

如果有買專業版本的話,有cache機制可以使用

修改cache參數
vi resin.xml

在cluster 內增加
<server-header> </server-header>
<resin:if test=”${resin.professional}”>
<cache memory-size=”64M”>
<rewrite-vary-as-private/>
</cache>
</resin:if>

 

在<web-app-deploy 底下增加
<web-app-default>
<prologue>
<allow-servlet-el/>
</prologue>

<session-config>
<use-persistent-store/>
<enable-url-rewriting>false</enable-url-rewriting>
</session-config>

<resin:if test=”${resin.professional}”>
<cache-mapping url-pattern=”/” max-age=”5s”/>
<cache-mapping url-pattern=”*.gif” max-age=”60m”/>
<cache-mapping url-pattern=”*.jpg” max-age=”60m”/>
<cache-mapping url-pattern=”*.png” max-age=”60m”/>
<cache-mapping url-pattern=”*.css” max-age=”60s”/>
<cache-mapping url-pattern=”*.js” max-age=”60s”/>
</resin:if>
</web-app-default>

接著是啟動與停止指令
啟動
/usr/local/resin/bin/resin.sh start
停止
/usr/local/resin/bin/resin.sh stop

效能上來說比tomcat快上約40%

不過免費版本最好的就是搭配Nginx使用

比較彈性也方便

AWS-CLI簡易切換ELB Health check

在工作上因為盡可能要做到自動化

所以很多指令操作都寫成了一堆的shell script (誰叫我linux系的XD)

在公司的系統維護上因為有需要切換維護頁面的顯示,但是在產品設計上有跟nginx連動

所以在原本的ELB health check在tomcat關閉的時候需要切換到80 port的nginx維護頁面上

所以為了方便,寫了這個小工具

主要是用aws cli 與iam的身分去執行

#!/bin/bash

case $1 in
java)
aws elb configure-health-check –load-balancer-name jack-sim –health-check Target=HTTP:80/java/,Interval=15,UnhealthyThreshold=2,HealthyThreshold
=2,Timeout=3
;;
web)
aws elb configure-health-check –load-balancer-name jack-sim –health-check Target=HTTP:80/,Interval=15,UnhealthyThreshold=2,HealthyThreshold=2,Timeou
t=3
;;
*)
echo “Usage: $0 {java|web}”
esac
exit 0

主要就切換 80:/ 與 80:/java/ 兩個health check的監控存活頁面

畢竟在java更新重啟的時候會失效導致ELB將server抽掉,user無法正常瀏覽到維護畫面

所以切換給80由nginx判斷並顯示維護畫面,也可以透過nginx的判斷讓公司內部進入測試

 

© 2017 Kila's IT Home

Theme by Anders NorénUp ↑