我負責的許多 Application Server 逐漸移到 Docker 上,最近常遇到休個週末回來就不行了?原來是這些在 VM 裡的 Docker 為了節能減碳,公司的政策是預設每週會自動停機,當底下的 VM 重啟之後,可以檢查到 Application Server 即使是開著的,埠口是外露的,也都只能在 container 本機存取服務,外界一概連不進去。
如此一定先懷疑防火牆吧?怪的是又沒去改,為何上週可以而本週不行?而且即使是整個防火牆都關了,也只修好一半,由完全失聯到「准進不准出」,像是 Jenkins 連不到外面的 Plugin Update Center,或是 SonarQube 連不到認證的 LDAP Server 等等。
最後找到真正的解法是 Docker Service 必須重啟。
星期二, 11月 01, 2016
星期三, 10月 26, 2016
Docker-based SonarQube
首先當然是要把 Docker 裝好,再來照這裡的說明只要一行指令:
搭配 PostgreSQL 似乎更容易些,且效率、評價都好,精簡至四道指令完成:
- docker run -d --name sonarqube1 -p 9000:9000 sonarqube
- docker logs sonarqube1
- docker stop sonarqube1
- docker rm sonarqube1
- docker run -d --name sonarqube2 -p 80:9000 sonarqube
- docker exec -it sonarqube2 sh
- docker run -d --name mysql1 -e MYSQL_ROOT_PASSWORD=changeit mysql
- docker exec -it mysql1 sh
- mysql -u root -pchangeit
- create database sonardb;
- grant all on sonardb.* to sonaruser@'%' identified by 'sonarpass';
- flush privileges;
- exit
- exit
- docker inspect mysql1 | grep IPAddress
- docker run -d --name mysql2 --link mysql1 -e MYSQL_RANDOM_ROOT_PASSWORD=true mysql
- docker exec -it mysql2 sh
- mysql -h <mysql1_IPAddress> -u sonaruser -psonarpass
- show databases;
- exit
- exit
- docker run -d --name sonarqube3 -p 9000:9000 --link mysql1 -e SONARQUBE_JDBC_USERNAME=sonaruser -e SONARQUBE_JDBC_PASSWORD=sonarpass -e "SONARQUBE_JDBC_URL=jdbc:mysql://mysql1/sonardb?useUnicode=true&characterEncoding=utf8" sonarqube
搭配 PostgreSQL 似乎更容易些,且效率、評價都好,精簡至四道指令完成:
- docker run -d --name postgres1 postgres
- docker exec -it postgres1 createuser -U postgres -d -P -s sonar (input sonar / sonar)
- docker exec -it postgres1 createdb -U sonar sonar
- docker run -d --name sonarqube4 -p 9000:9000 --link postgres1 -e SONARQUBE_JDBC_URL=jdbc:postgresql://postgres1/sonar sonarqube
星期二, 10月 25, 2016
Red Hat Startup
CentOS 用這麼久了,原以為系出同門的 Red Hat 應該相去不遠才是,沒想到剛開始就踢到鐵板 - 沒有 yum?這樣是要叫人家怎麼裝東西?
好吧,先去 Red Hat 網站申請個帳號,再下指令:
好吧,先去 Red Hat 網站申請個帳號,再下指令:
- subscription-manager register --username 帳號 --password 密碼 --auto-attach
- ip a
Linux access by non-root
用 root 帳號存取 Linux 是方便也是危險的。試想有人要攻一部主機時,沒有帳號是不能猜密碼的,他首先會猜這上面有什麼帳號?又哪個帳號具有最大的權限,讓攻下之後的效益最大?
通常建議平時的操作都用普通的使用者,只有在需要的時候取 root 權限做事,也就是 sudo。例如要新建一個 user1 帳號(此時還是 root 身分):
通常建議平時的操作都用普通的使用者,只有在需要的時候取 root 權限做事,也就是 sudo。例如要新建一個 user1 帳號(此時還是 root 身分):
- userdel -r user1
- useradd user1
- passwd user1
- ## Allow root to run any commands anywhere
- root ALL=(ALL) ALL
- user1 ALL=(ALL) ALL
- ## Allows people in group wheel to run all commands
- %wheel ALL=(ALL) ALL
- usermod -aG wheel user1
星期二, 10月 11, 2016
Mac + VirtualBox + BlueStack => Crash
最近我 Mac 上的 Line 一直都不安份,常要求訊息加密(Letter Sealing)的身分驗證。由於沒有實體 Smartphone 的關係,一直要開 BlueStack 模擬很麻煩就算了,還會讓稍後再開 VirtualBox 的 Mac 當機!原來這兩個軟體是有些愛恨情仇的。而且 Bluestack 竟然也一年沒更新了,暫時就先關閉訊息加密吧,有空再找時間試試 Genymotion 能否取代掉 Bluestack。
SonarQube Analysis Fail?
我都是透過 Jenkins 向 Subversion 取得原始碼,再送給 SonarQube 分析,但有的專案順利,有的就不行,錯誤訊息像是:
關鍵在於 Jenkins 當然會有 Subversion 的帳密(用以取原始碼),但 SonarQube 也要?那是用來 blame 作者的。在 SonarQube 如此設定就能解決:
回頭再看那些順利的,歸納出一個差異:要不就是非 Subversion 的 VCS,要不就是帳號在 LDAP。結論:若是 Subversion 上的特殊帳號才會有此問題。
關鍵在於 Jenkins 當然會有 Subversion 的帳密(用以取原始碼),但 SonarQube 也要?那是用來 blame 作者的。在 SonarQube 如此設定就能解決:
回頭再看那些順利的,歸納出一個差異:要不就是非 Subversion 的 VCS,要不就是帳號在 LDAP。結論:若是 Subversion 上的特殊帳號才會有此問題。
星期五, 9月 30, 2016
Jenkins Cobertura Report Missing?
很久以前好不容易在 Jenkins 弄出來的 Cobertura 測試涵蓋度報表,最近再看竟然只剩頁框了?原來是因為 Content Security Policy 的緣故,要在啟動時加一個參數來避免:
- java -Dhudson.model.DirectoryBrowserSupport.CSP= -jar jenkins.war
- System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "sandbox; default-src 'none'; img-src 'self'; style-src 'self';") // default
- System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "default-src 'none'; img-src 'self'; style-src 'self'; child-src 'self'; frame-src 'self';") // for JavaDoc, may be working or not
- System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "") // work if no cache
- System.getProperty("hudson.model.DirectoryBrowserSupport.CSP") // check
訂閱:
文章 (Atom)
