Jenkins proxy: Cấu hình proxy cho plugin, agent và pipeline

Chuyên viên Kỹ thuật ProxyVN 09-20-2026 Đang tính... phút đọc

Jenkins proxy là bộ cấu hình giúp máy chủ Jenkins làm việc được khi đặt trong mạng công ty bắt buộc đi qua proxy. Không cấu hình đúng, Jenkins không tải được plugin, không kéo được mã từ GitHub, các bước npm, Maven hay Docker build trong pipeline đều thất bại. Điểm khó là Jenkins có ba lớp đọc proxy riêng biệt. Bài này ProxyVN hướng dẫn cấu hình cả ba lớp, kèm cách khoanh vùng lỗi nhanh. Tham khảo dịch vụ tại ProxyVN.

Tổng quan về Jenkins proxy

Nhiều anh em đặt proxy ở một chỗ rồi ngạc nhiên vì chỗ khác vẫn lỗi. Lý do là Jenkins không có một công tắc proxy chung cho mọi thứ. Hiểu cấu trúc trước sẽ tiết kiệm rất nhiều thời gian.

Vì sao Jenkins thường nằm sau proxy

Jenkins là máy chủ tích hợp liên tục, thường được đặt trong mạng nội bộ để truy cập kho mã, cơ sở dữ liệu thử nghiệm và máy chủ triển khai. Mạng nội bộ của doanh nghiệp, ngân hàng hay cơ quan thường không cho máy chủ ra Internet trực tiếp. Mọi kết nối ra ngoài phải đi qua proxy để kiểm soát và ghi nhật ký.

Trong khi đó, Jenkins lại cần Internet cho rất nhiều việc: tải plugin từ trung tâm cập nhật, kéo mã từ GitHub hay GitLab, tải thư viện npm, Maven, pip, kéo image Docker. Mỗi việc này đi qua một thành phần khác nhau và đọc cấu hình proxy theo cách khác nhau.

Ba lớp cấu hình riêng biệt

ProxyVN chia cấu hình thành ba lớp để dễ nhớ:

Lớp 1, trình quản lý plugin: cấu hình trong giao diện Manage Jenkins, lưu ở tệp `proxy.xml`, dùng để tải plugin và kiểm tra cập nhật.
Lớp 2, JVM của controller: tham số `-Dhttp.proxyHost` truyền vào Java khi khởi động Jenkins, dùng cho mã Java chạy trong controller.
Lớp 3, agent và pipeline: biến môi trường và cấu hình riêng của từng công cụ như git, npm, Maven, Docker chạy trên máy agent.

Lớp này không tự truyền sang lớp kia. Đặt proxy cho plugin xong, lệnh `npm install` trong pipeline vẫn không biết gì về proxy đó. Đây là điều quan trọng nhất cần nhớ trong cả bài.

Controller và agent

Jenkins hiện đại chia thành controller, máy điều phối và hiển thị giao diện, với các agent, máy thực sự chạy công việc build. Khuyến nghị của dự án là không chạy build trên controller. Vì vậy lớp 3 phải cấu hình trên từng agent, kể cả agent chạy dạng container tạo ra theo yêu cầu.

Cấu hình Jenkins proxy cho trình quản lý plugin

Ba lớp cần đặt proxy

Ba lớp cần đặt proxy

Đây là lớp đầu tiên anh em gặp, thường ngay trong trình hướng dẫn cài đặt lần đầu. Không có lớp này, Jenkins báo không kết nối được trung tâm cập nhật và không cài được plugin nào.

Trong trình hướng dẫn cài đặt lần đầu

Khi mở Jenkins lần đầu sau khi nhập mật khẩu khởi tạo, nếu máy không ra được Internet, trình hướng dẫn hiện trang báo Jenkins đang offline. Trang này có nút Configure Proxy. Bấm vào, anh em nhập thông tin proxy rồi thử lại, trình hướng dẫn sẽ tiếp tục bước chọn plugin gợi ý.

Nếu bỏ qua bước này, anh em vẫn vào được Jenkins nhưng không có plugin nào, kể cả plugin Git và Pipeline. Lúc đó cấu hình ở mục Advanced như hướng dẫn bên dưới rồi cài plugin sau.

Trong mục Advanced settings

Với Jenkins đã chạy, anh em làm theo các bước:

Vào Manage Jenkins, chọn Plugins.
Chọn tab Advanced settings.
Ở phần HTTP Proxy Configuration, điền Server là địa chỉ proxy, ví dụ `proxy.congty.vn`.
Điền Port, ví dụ `8080`.
Nếu proxy yêu cầu xác thực, điền User name và Password.
Ở ô No Proxy Host, liệt kê các máy nội bộ không đi qua proxy, mỗi dòng một mục, hỗ trợ ký tự `*`.
Bấm Submit để lưu.

Ngay dưới có phần kiểm tra với ô Test URL. Anh em nhập `https://updates.jenkins.io` rồi bấm Validate Proxy. Kết quả Success nghĩa là Jenkins đã ra được trung tâm cập nhật qua proxy.

Tệp proxy.xml

Cấu hình trên được lưu vào tệp `proxy.xml` trong thư mục `JENKINS_HOME`. Với hệ thống quản lý bằng mã, anh em có thể tạo sẵn tệp này hoặc dùng plugin Configuration as Code để khai báo trong YAML. Mật khẩu proxy trong tệp được mã hoá bằng khoá của Jenkins, chép tệp sang máy khác sẽ không giải mã được.

Cài plugin khi không có Internet

Một số môi trường cấm mọi kết nối ra ngoài, kể cả qua proxy. Theo tài liệu quản lý plugin của Jenkins, anh em có thể tải tệp `.hpi` từ máy khác rồi cài qua mục Deploy Plugin trong tab Advanced settings, sau đó khởi động lại controller. Cách khác là chép tệp vào thư mục `JENKINS_HOME/plugins` với đuôi `.jpi`.

Cách cài tay này mất công vì phải tự xử lý plugin phụ thuộc. Nếu có thể, xin bộ phận mạng mở proxy cho tên miền `updates.jenkins.io` và các máy chủ tải plugin là phương án dễ thở hơn nhiều.

Cấu hình Jenkins proxy cho JVM của controller

Lớp 2 ít người để ý nhưng gây ra những lỗi khó hiểu: cài plugin được, nhưng plugin gọi API bên ngoài như Slack, GitHub, Jira lại thất bại.

Khi nào cần lớp này

Nhiều plugin dùng cấu hình proxy chung của Jenkins ở lớp 1, nhưng một số thư viện Java bên trong lại đọc trực tiếp thuộc tính hệ thống của JVM. Các plugin gửi thông báo, gọi webhook ra ngoài, xác thực qua OAuth của bên thứ ba là nhóm hay gặp. Khi anh em thấy lỗi kết nối chỉ ở một plugin cụ thể dù lớp 1 đã chạy, nên thêm lớp 2.

Các thuộc tính proxy của Java

Theo tài liệu mạng của Java SE 21, JVM đọc các thuộc tính sau:

Bảng: Các thuộc tính proxy của Java
Thuộc tính	Mặc định	Ý nghĩa
http.proxyHost	Không có	Proxy cho kết nối HTTP
http.proxyPort	80	Cổng proxy HTTP
https.proxyHost	Không có	Proxy cho kết nối HTTPS
https.proxyPort	443	Cổng proxy HTTPS
http.nonProxyHosts	localhost, 127.*, [::1]	Máy đi thẳng, phân tách bằng dấu gạch đứng
socksProxyHost, socksProxyPort	Không có, 1080	Proxy SOCKS
java.net.useSystemProxies	false	Dùng proxy của hệ điều hành

Lưu ý `http.nonProxyHosts` dùng chung cho cả HTTP và HTTPS, các mục phân tách bằng dấu `|` chứ không phải dấu phẩy như biến NO_PROXY quen thuộc. Viết nhầm dấu phân tách là lỗi rất phổ biến.

Truyền tham số khi chạy bằng gói Linux

Jenkins cài bằng gói deb hoặc rpm chạy dưới systemd. Anh em tạo tệp override để thêm tham số Java:

sudo systemctl edit jenkins

[Service]
Environment="JAVA_OPTS=-Dhttp.proxyHost=proxy.congty.vn -Dhttp.proxyPort=8080 -Dhttps.proxyHost=proxy.congty.vn -Dhttps.proxyPort=8080 -Dhttp.nonProxyHosts=localhost|127.*|*.noibo.local|10.*"

sudo systemctl daemon-reload
sudo systemctl restart jenkins

Ghi chú dấu `|` nằm trong dấu ngoặc kép của dòng Environment nên không bị shell hiểu sai. Sau khi khởi động lại, anh em vào Manage Jenkins > System Information để xác nhận các thuộc tính đã xuất hiện.

Truyền tham số khi chạy bằng Docker

Image chính thức `jenkins/jenkins` đọc biến `JAVA_OPTS`. Trong tệp compose, anh em khai báo như sau:

services:
  jenkins:
    image: jenkins/jenkins:lts-jdk21
    ports:
      - "8080:8080"
      - "50000:50000"
    environment:
      JAVA_OPTS: >-
        -Dhttp.proxyHost=proxy.congty.vn -Dhttp.proxyPort=8080
        -Dhttps.proxyHost=proxy.congty.vn -Dhttps.proxyPort=8080
        -Dhttp.nonProxyHosts=localhost|127.*|*.noibo.local
    volumes:
      - jenkins_home:/var/jenkins_home
 
volumes:
  jenkins_home:

Xác thực proxy ở lớp JVM phức tạp hơn vì Java mặc định tắt Basic khi mở đường hầm HTTPS qua CONNECT, qua thuộc tính `jdk.http.auth.tunneling.disabledSchemes`. Nếu proxy công ty dùng Basic, cần đặt thuộc tính này về rỗng. Tốt hơn là nhờ bộ phận mạng cho máy chủ Jenkins đi qua proxy theo IP, không cần mật khẩu.

Cấu hình Jenkins proxy cho agent và pipeline

Tải plugin qua proxy công ty

Tải plugin qua proxy công ty

Lớp 3 là nơi diễn ra phần lớn công việc thật. Mỗi lệnh trong pipeline là một tiến trình riêng trên agent, đọc proxy theo quy tắc của chính công cụ đó.

Biến môi trường chung trên agent

Phần lớn công cụ dòng lệnh đọc biến `http_proxy`, `https_proxy` và `no_proxy`. Cách gọn nhất là đặt biến ở cấp agent để mọi công việc chạy trên đó đều nhận. Trong Jenkins, vào Manage Jenkins > Nodes, chọn agent, vào Configure, tích Environment variables rồi thêm từng biến.

Nên đặt cả chữ hoa và chữ thường vì mỗi công cụ đọc một kiểu. Curl ưu tiên chữ thường, một số công cụ Java và Go đọc chữ hoa. Đặt đủ cả hai tránh được những lỗi chỉ xảy ra với một công cụ.

Khai báo trong Jenkinsfile

Với pipeline khai báo, anh em đặt biến trong khối `environment`. Mật khẩu proxy nên lưu trong Credentials thay vì ghi thẳng vào Jenkinsfile:

pipeline {
  agent any
  environment {
    PROXY_CRED  = credentials('proxy-congty')
    HTTP_PROXY  = "http://${PROXY_CRED_USR}:${PROXY_CRED_PSW}@proxy.congty.vn:8080"
    HTTPS_PROXY = "http://${PROXY_CRED_USR}:${PROXY_CRED_PSW}@proxy.congty.vn:8080"
    NO_PROXY    = 'localhost,127.0.0.1,.noibo.local,10.0.0.0/8'
    http_proxy  = "${HTTP_PROXY}"
    https_proxy = "${HTTPS_PROXY}"
    no_proxy    = "${NO_PROXY}"
  }
  stages {
    stage('Kiểm tra') {
      steps {
        sh 'curl -sS https://api.ipify.org'
      }
    }
  }
}

Hàm `credentials()` với loại Username with password tự sinh hai biến đuôi `_USR` và `_PSW`. Jenkins che mật khẩu trong nhật ký console bằng dấu sao, nhưng nếu lệnh in ra cả URL proxy, phần mật khẩu vẫn có thể lộ, nên tránh echo các biến này.

NO_PROXY cho máy chủ nội bộ

Kho Git nội bộ, kho Nexus hay Artifactory, máy chủ SonarQube thường nằm trong mạng công ty. Đi vòng qua proxy vừa chậm vừa có thể bị chặn. Anh em liệt kê đủ các tên miền và dải IP nội bộ trong NO_PROXY. Cú pháp chi tiết, kể cả cách viết dấu chấm đầu tên miền, có trong bài no_proxy là gì.

Jenkins proxy cho từng công cụ trong pipeline

Pipeline gọi công cụ qua proxy

Pipeline gọi công cụ qua proxy

Biến môi trường giải quyết phần lớn trường hợp, nhưng vài công cụ phổ biến có cách đọc proxy riêng. Phần này đi nhanh qua từng công cụ, chi tiết sâu hơn nằm ở các bài riêng.

Git

Plugin Git của Jenkins mặc định dùng git dòng lệnh, theo trang plugin Git đây là bản triển khai đầy đủ tính năng nhất. Git dòng lệnh đọc biến `https_proxy` hoặc cấu hình `http.proxy` trong `.gitconfig` của người dùng chạy agent. Cách bền vững nhất là cấu hình một lần trên agent:

git config --global http.proxy http://proxy.congty.vn:8080
git config --global http.https://git.noibo.local.proxy ""

Dòng thứ hai bỏ proxy riêng cho kho nội bộ. Clone qua SSH thì không dùng proxy HTTP, phải cấu hình ProxyCommand trong SSH. Chi tiết có trong bài git proxy.

npm và Node.js

Npm đọc biến môi trường nhưng còn có cấu hình riêng trong `.npmrc`, và cấu hình riêng này được ưu tiên. Một `.npmrc` cũ còn sót trên agent với proxy sai sẽ làm build lỗi dù biến môi trường đúng. Kiểm tra bằng `npm config get proxy` ngay trong pipeline khi nghi ngờ. Bài npm proxy có hướng dẫn cho cả yarn và pnpm.

Maven và Gradle

Maven không đọc biến môi trường proxy, nó chỉ đọc mục `proxies` trong `settings.xml`. Jenkins có plugin Config File Provider để quản lý tệp này tập trung và truyền vào lệnh `mvn -s`. Gradle đọc thuộc tính `systemProp.https.proxyHost` trong `gradle.properties`. Cấu hình chi tiết cho hai công cụ có trong bài Maven và Gradle proxy.

Docker build và pull

Docker có hai chỗ cần proxy. Docker daemon cần proxy để kéo image, cấu hình qua tệp override của systemd. Lệnh `docker build` cần proxy cho các lệnh `RUN apt-get`, `RUN npm install` bên trong Dockerfile, truyền qua `--build-arg HTTP_PROXY=...`. Hai chỗ này độc lập, bài proxy Docker giải thích kỹ.

Jenkins proxy với agent chạy trong container và Kubernetes

Nhiều hệ thống hiện nay tạo agent động: mỗi lần build, Jenkins tạo một container hay pod mới, chạy xong là xoá. Cấu hình trên giao diện Nodes không áp dụng được cho agent loại này.

Đặt biến trong mẫu pod

Với plugin Kubernetes, anh em khai báo biến môi trường proxy trong mẫu pod, áp dụng cho mọi container trong pod. Cách này đảm bảo mọi agent sinh ra đều có proxy mà không phải nhớ khai báo trong từng Jenkinsfile:

apiVersion: v1
kind: Pod
spec:
  containers:
    - name: node
      image: node:22
      command: ["sleep"]
      args: ["infinity"]
      env:
        - name: HTTPS_PROXY
          value: "http://proxy.congty.vn:8080"
        - name: NO_PROXY
          value: "localhost,127.0.0.1,.svc,.cluster.local,10.0.0.0/8"

Trên Kubernetes, NO_PROXY phải có thêm `.svc` và `.cluster.local` để các container gọi nhau trong cụm không đi vòng qua proxy. Thiếu mục này, agent sẽ không kết nối được về controller Jenkins qua tên dịch vụ nội bộ.

Image agent dựng sẵn proxy

Một cách khác là dựng image agent riêng có sẵn cấu hình proxy cho git, npm, Maven. Cách này tiện khi đội dùng nhiều công cụ, nhưng phải dựng lại image mỗi khi proxy đổi. ProxyVN khuyên giữ proxy ở biến môi trường, chỉ đóng gói vào image những cấu hình không chứa mật khẩu.

Jenkins proxy khi chạy trên Windows

Không ít doanh nghiệp chạy Jenkins trên Windows Server vì cần build ứng dụng .NET hay phần mềm desktop. Cách đặt proxy trên Windows khác Linux ở vài điểm nhỏ nhưng dễ vấp.

Controller chạy dạng dịch vụ Windows

Bộ cài MSI đăng ký Jenkins thành dịch vụ Windows. Theo hướng dẫn cài đặt Jenkins, tham số Java của dịch vụ nằm trong tệp `jenkins.xml` ở thư mục cài đặt. Anh em mở tệp bằng quyền quản trị, tìm thẻ `arguments` rồi thêm các tham số `-Dhttp.proxyHost`, `-Dhttps.proxyHost` cùng cổng vào trước phần `-jar`.

Sau khi lưu, khởi động lại dịch vụ trong Services hoặc bằng lệnh `Restart-Service jenkins` trên PowerShell chạy quyền quản trị. Kiểm tra lại trong System Information như với Linux.

Agent Windows và tài khoản dịch vụ

Agent chạy dạng dịch vụ thường dùng tài khoản Local System hoặc một tài khoản dịch vụ riêng. Biến môi trường người dùng đặt khi đăng nhập bằng tài khoản cá nhân sẽ không áp dụng cho tài khoản này. Anh em đặt biến ở cấp hệ thống trong System Properties, hoặc đặt trong cấu hình node của Jenkins như đã hướng dẫn.

Một điểm khác là nhiều công cụ trên Windows như PowerShell `Invoke-WebRequest` hay .NET đọc proxy hệ thống theo WinHTTP chứ không theo biến môi trường. Lệnh `netsh winhttp set proxy proxy.congty.vn:8080` đặt proxy cho WinHTTP, áp dụng cho các dịch vụ chạy nền.

Kiểm tra Jenkins proxy sau khi cấu hình

Cấu hình xong mà không kiểm tra là để lỗi chờ đến lúc build quan trọng mới lộ ra. Một pipeline kiểm tra ngắn giúp xác nhận cả ba lớp đều hoạt động.

Pipeline kiểm tra nhanh

Anh em tạo một job pipeline riêng, chạy trên từng loại agent, với các bước gọi thử những điểm đến quan trọng. Ví dụ dưới đây do ProxyVN viết để minh hoạ:

pipeline {
  agent { label 'linux' }
  stages {
    stage('Bien moi truong') {
      steps { sh 'env | grep -i _proxy | sed "s/:[^:@]*@/:***@/"' }
    }
    stage('Ra Internet') {
      steps { sh 'curl -sSI https://updates.jenkins.io | head -1' }
    }
    stage('Git') {
      steps { sh 'git ls-remote https://github.com/jenkinsci/jenkins.git HEAD' }
    }
    stage('npm') {
      steps { sh 'npm view express version' }
    }
  }
}

Bước đầu tiên in các biến proxy nhưng thay mật khẩu bằng dấu sao. Các bước còn lại thử lần lượt kết nối thẳng, git và npm. Bước nào đỏ thì biết ngay công cụ nào chưa nhận proxy.

Chạy định kỳ để phát hiện sớm

Đặt job này chạy mỗi sáng bằng tuỳ chọn Build periodically. Khi proxy công ty đổi mật khẩu hay đổi quy tắc, job kiểm tra sẽ đỏ trước khi các đội phát triển gặp lỗi trong build thật. Gắn thông báo email hoặc chat cho job này để người quản trị biết ngay.

Sửa lỗi thường gặp với Jenkins proxy

Khoanh vùng lỗi kết nối

Khoanh vùng lỗi kết nối

Lỗi proxy trong Jenkins thường hiện dưới dạng thông báo chung chung như "Connection timed out" hay "Unable to connect". Khoanh vùng đúng lớp là bước quan trọng nhất.

Xác định lỗi thuộc lớp nào

Anh em đặt ba câu hỏi theo thứ tự. Lỗi xảy ra khi cài plugin hay kiểm tra cập nhật thì thuộc lớp 1. Lỗi xảy ra trong một plugin chạy trên controller, như gửi thông báo, thì thuộc lớp 2. Lỗi xảy ra trong nhật ký console của một bước build thì thuộc lớp 3.

Với lớp 3, thêm một bước `sh 'env | grep -i proxy'` ngay đầu pipeline để xem agent thực sự nhận biến gì. Rất nhiều lỗi được phát hiện ngay ở bước này vì biến bị đặt sai tên hoặc không truyền xuống container.

Lỗi 407 Proxy Authentication Required

Mã 407 nghĩa là proxy cần xác thực mà yêu cầu không gửi kèm, hoặc gửi sai. Ở lớp 1, kiểm tra lại User name và Password trong Advanced settings. Ở lớp 2, kiểm tra thuộc tính tắt Basic khi mở đường hầm như đã nói. Ở lớp 3, kiểm tra mật khẩu có ký tự đặc biệt chưa được mã hoá URL, ví dụ `@` phải viết thành `%40`.

Proxy dùng xác thực NTLM của Windows là trường hợp khó nhất, nhiều công cụ không hỗ trợ. Giải pháp thường dùng là dựng một proxy trung gian như CNTLM trên agent, nhận kết nối không cần mật khẩu rồi xác thực NTLM thay cho công cụ.

Lỗi chứng chỉ khi proxy giải mã HTTPS

Nhiều proxy doanh nghiệp giải mã HTTPS để kiểm tra nội dung, thay chứng chỉ của trang đích bằng chứng chỉ do CA công ty ký. Jenkins báo lỗi `PKIX path building failed`, git báo `SSL certificate problem`. Cách đúng là thêm chứng chỉ gốc của công ty vào kho tin cậy của Java bằng `keytool` và vào kho chứng chỉ hệ điều hành của agent.

Tắt kiểm tra chứng chỉ trong git hay npm có thể làm build chạy được, nhưng mở ra rủi ro bị tấn công trung gian. Chỉ nên dùng tạm khi chẩn đoán.

Test URL báo thành công nhưng vẫn lỗi

Validate Proxy chỉ kiểm tra lớp 1 với đúng địa chỉ đã nhập. Trung tâm cập nhật có thể chuyển hướng tải plugin sang máy chủ mirror ở tên miền khác, nếu proxy chỉ cho phép một số tên miền, việc tải vẫn thất bại. Xem nhật ký Jenkins để biết tên miền nào bị chặn rồi đề nghị bộ phận mạng mở thêm.

Bảo mật thông tin Jenkins proxy

Mật khẩu proxy công ty thường chính là tài khoản miền của một người hoặc một tài khoản dịch vụ có quyền ra Internet. Lộ mật khẩu này nghĩa là người ngoài có thể đi ra Internet dưới danh nghĩa công ty, nên cần bảo vệ cẩn thận.

Dùng tài khoản dịch vụ riêng

Đừng dùng tài khoản cá nhân của quản trị viên cho proxy của Jenkins. Khi người đó nghỉ việc hoặc đổi mật khẩu, toàn bộ build sẽ dừng. Anh em xin bộ phận mạng cấp một tài khoản dịch vụ riêng cho Jenkins, chỉ có quyền đi qua proxy, không có quyền đăng nhập máy tính hay đọc email.

Tốt hơn nữa là cho dải IP của máy chủ Jenkins và agent đi qua proxy không cần mật khẩu. Không có mật khẩu thì không có gì để lộ, và cấu hình các công cụ cũng gọn hơn nhiều.

Giới hạn ai được xem cấu hình

Trong Jenkins, người có quyền Administer xem được mọi cấu hình, kể cả phần proxy. Người có quyền cấu hình job có thể viết pipeline in ra biến môi trường. Anh em dùng plugin phân quyền như Role-based Authorization Strategy để giới hạn quyền cấu hình job ở những người cần thiết.

Không bao giờ ghi mật khẩu proxy thẳng vào Jenkinsfile đẩy lên kho mã. Mọi người có quyền đọc kho đều thấy, kể cả sau khi đã xoá khỏi lịch sử gần nhất, vì Git lưu lại toàn bộ các phiên bản cũ.

Kinh nghiệm vận hành Jenkins proxy lâu dài

Cấu hình xong một lần chưa phải là hết. Proxy công ty đổi mật khẩu, đổi địa chỉ, thêm quy tắc mới đều có thể làm Jenkins ngừng hoạt động.

Tập trung cấu hình một chỗ

Khi proxy được khai báo rải rác ở giao diện, JAVA_OPTS, từng agent, từng Jenkinsfile, mỗi lần đổi mật khẩu là một lần đi sửa khắp nơi. Anh em nên dùng Configuration as Code cho lớp 1, Credentials cho mật khẩu, và một thư viện pipeline dùng chung để đặt biến môi trường cho lớp 3. Đổi mật khẩu chỉ cần sửa Credentials.

Ghi lại danh sách tên miền cần mở

Lập một danh sách tên miền Jenkins và các công cụ build cần truy cập: trung tâm cập nhật, GitHub, kho npm, Maven Central, Docker Hub. Danh sách này giúp làm việc với bộ phận mạng rõ ràng, và giúp kiểm tra nhanh khi có lỗi mới xuất hiện.

Với Jenkins, proxy không phải một cấu hình mà là ba cấu hình. Ghi nhớ điều này là đã giải được một nửa số lỗi kết nối.

Proxy riêng cho kiểm thử theo vùng

Một số đội cần chạy kiểm thử giao diện hay kiểm tra quảng cáo hiển thị đúng theo khu vực, đòi hỏi IP của một quốc gia cụ thể. Trường hợp này khác proxy công ty, chỉ một vài bước kiểm thử cần đi qua proxy theo vùng. Anh em truyền proxy riêng cho đúng bước đó qua biến môi trường của stage, không đặt toàn cục.

Khi cần IP Việt Nam cho các bước kiểm thử như vậy, anh em có thể mua proxy uy tín tại ProxyVN, gồm dân cư tĩnh Viettel, VNPT, FPT và datacenter Việt Nam, hỗ trợ HTTP và SOCKS5, cấp sẵn tên đăng nhập và mật khẩu để lưu vào Credentials của Jenkins.

Kết luận

Jenkins proxy gồm ba lớp độc lập: trình quản lý plugin, JVM của controller và môi trường của agent cùng từng công cụ trong pipeline. Cấu hình đủ ba lớp, khai báo NO_PROXY cho máy nội bộ và lưu mật khẩu trong Credentials là hệ thống chạy ổn định. Cần tư vấn thêm, hãy liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khi cấu hình Jenkins proxy.