TeamCity持續整合和持續交付Docker
TeamCity伺服器 - 強大的持續整合和持續交付功能
該映象適用於生產用途和評估目的。
鏡像標籤
docker映像中的所有預設標記都指向Linux映像。 Windows Docker映象有後綴-windowsservercore
和-nanoserver
jetbrains/teamcity-server
,jetbrains/teamcity-server:latest
(ubuntu)jetbrains/teamcity-server:latest-windowsservercore
,jetbrains/teamcity-server:latest-windowsservercore-ltsc2016
jetbrains/teamcity-server:latest-nanoserver
,jetbrains/teamcity-server:latest-nanoserver-sac2016
(nanoserver sac2016)jetbrains/teamcity-server:latest-windowsservercore-1709
(windowsservercore 1709)jetbrains/teamcity-server:latest-nanoserver-1709
(nanoserver 1709)
如何使用映象
從Docker Hub儲存庫中提取映象
docker pull jetbrains/teamcity-server
使用以下命令在Linux容器內使用TeamCity伺服器啟動容器:
docker run -it --name teamcity-server-instance \ -v <path to data directory>:/data/teamcity_server/datadir \ -v <path to logs directory>:/opt/teamcity/logs \ -p <port on host>:8111 \ jetbrains/teamcity-server
或Windows 容器
docker run -it --name teamcity-server-instance
-v <path to data directory>:C:/ProgramData/JetBrains/TeamCity
-v <path to logs directory>:C:/TeamCity/logs
-p <port on host>:8111
jetbrains/teamcity-server:latest-nanoserver
<path to data directory>是作為TeamCity資料目錄的主機計算機目錄,其中TeamCity儲存專案設定和構建結果。 通過空目錄為全新的開始。 未設定對映時,您將在容器關閉時失去所有TeamCity設定。
<path to logs directory>是儲存TeamCity伺服器日誌的主機目錄。 對映可以省略,但是在容器關閉時日誌將會丟失,這將使問題調查變得不可能。
除了資料目錄之外,TeamCity還儲存一組使用者並在SQL資料庫中建立結果。
預設情況下,TeamCity伺服器使用儲存在資料目錄下檔案系統上的內部資料庫。
Windows容器限制
有關Windows容器中已知問題的詳細資訊,請參閱已知問題頁面。
其他命令
當需要將其他環境變數傳遞給伺服器程序時,請使用常規-e選項。 例如 要傳遞TEAMCITY_SERVER_MEM_OPTS環境變數,請使用:
docker run -it --name teamcity-server-instance \
-e TEAMCITY_SERVER_MEM_OPTS="-Xmx2g -XX:MaxPermSize=270m -XX:ReservedCodeCacheSize=350m" \
-v <path to data directory>:/data/teamcity_server/datadir \
-v <path to log directory>:/opt/teamcity/logs \
-p <port on host>:8111 \
jetbrains/teamcity-server
要執行maintainDB指令碼(例如,用於伺服器備份),請停止正在執行的容器並從主機執行以下命令:
docker run -it --name teamcity-server-instance \
-v <path to data directory>:/data/teamcity_server/datadir \
-v <path to log directory>:/opt/teamcity/logs \
-p <port on host>:8111 \
jetbrains/teamcity-server \
"/opt/teamcity/bin/maintainDB.sh" "backup"
確保所有本地系統路徑與主伺服器啟動命令保持一致。要更改TomCat容器內的TeamCity應用程式的上下文,請通過
-e TEAMCITY_CONTEXT=/context
至 docker run 預設的一個是ROOT,意味著伺服器可以在http:// host /
升級TeamCity
確保檢查通用的TeamCity升級說明。
如果你沒有改變容器,你可以停止正在執行的容器,通過通常的命令將新版本的影象和伺服器拉入。
如果您更改了影象,則需要將更改複製到新的TeamCity伺服器映像。 一般來說,使用Docker的常識來執行升級。
許可
TeamCity可免費使用100個構建配置(作業)和3個代理的限制。 許可細節。
反饋
向TeamCity官方問題跟蹤器報告建議問題。
在Hood之下
此圖片基於TeamCity基礎影象構建,其中包括:
- ubuntu:xenial(Linux)
- microsoft / windowsservercore或microsoft / nanoserver(Windows)
- Oracle JRE 8 Update 161,64位
- curl,unzip(Linux)
限制
由於Oracle許可證策略,該映像基於JRE 8 Update 161,並提供有限的Java工具集。 如果您需要Java診斷工具(例如,為TeamCity程序進行記憶體轉儲或進行執行緒轉儲),請通過現有的Java安裝將JDK 8 Update 161,64位安裝到容器中。
其他TeamCity映象
Dockerfile原始碼
相關推薦
TeamCity持續整合和持續交付Docker
TeamCity伺服器 - 強大的持續整合和持續交付功能該映象適用於生產用途和評估目的。鏡像標籤docker映像中的所有預設標記都指向Linux映像。 Windows Docker映象有後綴-windowsservercore 和-nanoserverjetbrains/te
CI/CD 持續整合和持續交付 (一)
在網際網路時代,對於每一個企業,公司,產品快速迭代的重要性不言而喻,針對敏捷開發以使用CICD來完成。但是持續整合和持續交付(CI/CD)其實並沒有那麼容易實現,開發和運維總是忙裡忙外,最後還吃力不
CI/CD 持續整合和持續交付 (二)
根據上次的文章介紹,制定了一套解決方案 此套方案 作為 PaaS 或者SaaS 都是棒棒的,結合著openstack 作為IaaS層 更適合, 整體的思路大概是這樣的,後續會詳細介紹。 客戶或產品有新的需求變更,或者測試人員提出bug時,會在redmine服務上建立提交事
SpringBoot+Docker+Git+Jenkins實現簡易的持續整合和持續部署
努力了這麼久,但凡有點兒天賦,也該有些成功的跡象了。 前言 本篇文章引導你使用Jenkins部署SpringBoot專案,同時使用Docker和Git實現簡單的持續整合和持續部署。(專案地址:sso-merryyou) 流程圖如下:
基於jenkins構建應用的docker映象做持續整合和部署
為了做持續的整合和部署,引入了jenkins,利用jenkins來構建應用的docker映象並push到私有倉庫,然後再基於應用的docker映象來發布專案,這樣減少了很多的手動操作,基本能實現持續整合
致產品經理: 持續整合、持續交付、持續部署和DevOps
美好的週末又要來臨,小數就不跟大家聊沉甸甸的程式碼了,讓我們輕鬆一下換個話題。今天的主角是產品經理,程式設計師史蒂夫、安妮和喬伊友情客串,報幕員兼跑龍套就是可愛的小數啦,接下來精彩馬上開始—— 即使產品經理每週都在與開發團隊討論新功能,團隊協作緊密無間,在不斷的PUSH下,新功能比以往看起來上線和更新
DevOps學習-持續整合,持續交付和持續部署
(以下源引於網路,非本人原創,純粹是為了方便理解和回顧):首先是DevOps:Continuous Integration, Continuous Delivery, Continuous Deployment
持續整合,持續交付,持續部署聯絡和區別
iOS持續部署整合Jenkins或者Travis 部署蒲公英或者fir.im 極限程式設計的一種,總結ing… 經常會聽到持續整合,持續交付,持續部署,三者究竟是什麼,有何聯絡和區別呢? 假如把開發工作流程分為以下幾個階段: 編碼 -> 構建 -
CI與CD--從持續整合到持續交付
產品研發生命週期演化史: 1 純人肉構建 這是發生在我身上的7年前的故事,我們的專案每週四會發佈一個新版本,大家在每週四的晚上買好乾糧飲料熬夜苦戰。研發人員先提交程式碼,你merge我我merge,忙得不可開交;測試人員們則無事可做耐心等待。夜晚10點鐘,研發人員終於憋出來一個build的過
Jenkins+Sonar搭建持續整合和程式碼質量檢查環境
Jenkins+Sonar搭建 一、相關環境及下載地址 二、軟體安裝 Jenkins安裝 命令:dpkg –i jenkins_2.121.3_all.deb 若有報錯,執行# apt-get update 和# apt-get –f install, # ln -s /opt/jdk1.8.0_131/b
敏捷開發:持續整合與持續交付
敏捷開發是我們的常聽的名詞,什麼是敏捷開發? 說讓開發更簡化更高效等於沒說。。敏捷開發的關鍵詞是:持續整合與持續交付。 一個Java專案,一個人怎麼搞: 一個人寫程式碼 => 自己打包 => 自己機器編譯=> 自己部署 =>
簡單理解持續整合、持續交付、持續部署
「持續整合(Continuous Integration)」、「持續交付(Continuous Delivery)」和「持續部署(Continuous Deployment)」這三個概念有很詳細的解釋。這裡借用文中的插圖,說一下我對這三個概念的理解。 持續整合
談談持續整合、持續交付、持續部署
經常會聽到持續整合,持續交付,持續部署,三者究竟是什麼,有何聯絡和區別呢?什麼是“持續”? 所謂的持續,就是說每完成一個完整的部分,就向下個環節交付,發現問題可以馬上調整。是的問題不會放大到其他部分和後面的環節。 這種做法的核心思想在於:既然事實上難以做到事先完全瞭解完整
持續整合、持續交付、持續部署
1.持續整合 網際網路軟體的開發和釋出,已經形成了一套標準流程,最重要的組成部分就是持續整合(Continuous integration,簡稱CI)。 持續整合指的是,頻繁地(一天多次)將程式碼整合到主幹。 它的好處主要有兩個: 快速發現錯誤。 防止分支大
資料庫的持續整合和版本控制
在提出版本化資料庫工作是一個必要規則這一觀點之後,Scott Allen又詳述了一個做好版本化資料庫的方法,他給出了一個易於理解、實踐性很強的方法,通過建立基線、使用變更指令碼的方法來管理資料庫的修訂、控制程式化資料庫物件(如檢視、儲存過程、函式和觸發器),並充分利用分支和合並。 Allen在釋出了關係型
持續整合、持續交付GoCD中文網開通啦
如果大家使用過Jenkins那麼相信大家對於持續整合非常熟悉。今天要給大家介紹的是另一個非常強大的CD工具GoCD官方對其也稱之為GO但是要明白他和go語言golang是沒有多大關係的,他是使用java語言開發的。如果你真在使用Jenkins你肯定在疑惑為什麼要
什麼是持續整合?持續交付?持續部署?
一、概念 持續整合指的是,頻繁地(一天多次)將程式碼整合到主幹。 它的好處主要有兩個。 (1)快速發現錯誤。每完成一點更新,就整合到主幹,可以快速發現錯誤,定位錯誤也比較容易。 (2)防止分支大幅偏離主幹。如果不是經常整合,主幹又在不斷更新,會導致以後整合的難度變大,甚至難以整合。
談談持續整合,持續交付,持續部署之間的區別
經常會聽到持續整合,持續交付,持續部署,三者究竟是什麼,有何聯絡和區別呢? 假如把開發工作流程分為以下幾個階段: 編碼 -> 構建 -> 整合 -> 測試 -> 交付 -> 部署 正如你在上圖中看到,「持續整合(Continuous Integration)」、「持續
CI / CD 持續整合和部署 相關概念
文章目錄 什麼是CI / CD?其意義何在? CI/CD持續整合/持續部署定義 持續整合 持續部署 補:持續交付 與DevOps的關係 與持續部署的關
基於容器服務的持續整合與雲端交付(二)- 多維度打磨交付能力
前言 在上一篇中,和大家一起討論了傳統軟體交付的問題、持續交付的難點、以及為什麼雲端的容器交付可以協助大家快速的持續交付。 但是當真正的將一個系統通過雲端容器交付的時候會發現不能單純的將Docker作為一種交付工具來對待,更多的時候是作為一個交付平臺的基礎設施來看待,還需要關心的是使用Docker後網