OpenShift - Hướng dẫn nhanh

OpenShift là một Nền tảng phát triển đám mây dưới dạng Dịch vụ (PaaS) được lưu trữ bởi Red Hat. Đó là một nền tảng thân thiện với người dùng dựa trên đám mây mã nguồn mở được sử dụng để tạo, thử nghiệm và chạy các ứng dụng và cuối cùng là triển khai chúng trên đám mây.

OpenShift có khả năng quản lý các ứng dụng được viết bằng các ngôn ngữ khác nhau, chẳng hạn như Node.js, Ruby, Python, Perl và Java. Một trong những tính năng chính của OpenShift là nó có thể mở rộng, giúp người dùng hỗ trợ ứng dụng được viết bằng các ngôn ngữ khác.

OpenShift đi kèm với các khái niệm ảo hóa khác nhau như là lớp trừu tượng của nó. Khái niệm cơ bản đằng sau OpenShift dựa trên ảo hóa.

Ảo hóa

Nói chung, ảo hóa có thể được định nghĩa là việc tạo ra một hệ thống ảo chứ không phải là phiên bản vật lý hoặc thực tế của bất kỳ thứ gì bắt đầu từ hệ thống, bộ nhớ hoặc hệ điều hành. Mục tiêu chính của ảo hóa là làm cho cơ sở hạ tầng CNTT có khả năng mở rộng và đáng tin cậy hơn. Khái niệm ảo hóa đã có từ nhiều thập kỷ và với sự phát triển của ngành CNTT ngày nay, nó có thể được áp dụng cho nhiều tầng khác nhau, bắt đầu từ mức hệ thống, mức phần cứng, đến mức ảo hóa máy chủ.

Làm thế nào nó hoạt động

Nó có thể được mô tả như một công nghệ trong đó bất kỳ ứng dụng hoặc hệ điều hành nào được trừu tượng hóa từ lớp vật lý thực tế của nó. Một công dụng chính của công nghệ ảo hóa là ảo hóa máy chủ, sử dụng phần mềm gọi là hypervisor để trừu tượng hóa lớp khỏi phần cứng bên dưới. Hiệu suất của hệ điều hành chạy trên ảo hóa cũng tốt như khi nó đang chạy trên phần cứng vật lý. Tuy nhiên, khái niệm ảo hóa là phổ biến vì hầu hết hệ thống và ứng dụng đang chạy không yêu cầu sử dụng phần cứng bên dưới.

Kiến trúc vật lý và ảo

Các loại ảo hóa

  • Application Virtualization- Trong phương pháp này, ứng dụng được trừu tượng hóa từ hệ điều hành bên dưới. Phương pháp này rất hữu ích trong đó ứng dụng có thể được chạy một cách độc lập mà không bị phụ thuộc vào hệ điều hành bên dưới.

  • Desktop Virtualization- Phương pháp này được sử dụng để giảm tải máy trạm trong đó người ta có thể truy cập máy tính để bàn từ xa bằng cách sử dụng một máy khách mỏng tại bàn làm việc. Trong phương pháp này, các máy tính để bàn chủ yếu được chạy trong một trung tâm dữ liệu. Một ví dụ cổ điển có thể là Hình ảnh máy tính để bàn ảo (VDI) được sử dụng trong hầu hết các tổ chức.

  • Data Virtualization - Là một phương pháp trừu tượng hóa và tách khỏi phương pháp quản lý dữ liệu và dữ liệu truyền thống.

  • Server Virtualization- Trong phương pháp này, các tài nguyên liên quan đến máy chủ được ảo hóa bao gồm máy chủ vật lý, quy trình và hệ điều hành. Phần mềm cho phép trừu tượng hóa này thường được gọi là hypervisor.

  • Storage Virtualization - Đây là quá trình gộp nhiều thiết bị lưu trữ vào một thiết bị lưu trữ duy nhất được quản lý từ một bảng điều khiển trung tâm duy nhất.

  • Network Virtualization - Đây là phương pháp trong đó tất cả các tài nguyên mạng có sẵn được kết hợp bằng cách chia nhỏ băng thông và các kênh có sẵn, mỗi tài nguyên này độc lập với nhau.

OpenShift

OpenShift là một nền tảng ứng dụng hỗ trợ đám mây như một Dịch vụ (PaaS). Đó là một công nghệ mã nguồn mở giúp các tổ chức di chuyển cơ sở hạ tầng và nền tảng ứng dụng truyền thống của họ từ phương tiện vật lý, ảo sang đám mây.

OpenShift hỗ trợ rất nhiều ứng dụng khác nhau, có thể dễ dàng phát triển và triển khai trên nền tảng đám mây OpenShift. Về cơ bản OpenShift hỗ trợ ba loại nền tảng cho các nhà phát triển và người dùng.

Cơ sở hạ tầng như một dịch vụ (IaaS)

Ở định dạng này, nhà cung cấp dịch vụ cung cấp các máy ảo cấp phần cứng với một số cấu hình phần cứng ảo được xác định trước. Có nhiều đối thủ cạnh tranh trong không gian này, bắt đầu từ đám mây AWS Google, Rackspace, v.v.

Hạn chế chính của việc có IaaS sau một quá trình thiết lập và đầu tư lâu dài là người ta vẫn phải chịu trách nhiệm cài đặt và bảo trì hệ điều hành và gói máy chủ, quản lý mạng cơ sở hạ tầng và quản trị hệ thống cơ bản.

Phần mềm như một dịch vụ (SaaS)

Với SaaS, người ta ít phải lo lắng nhất về cơ sở hạ tầng bên dưới. Nó đơn giản như plug and play, trong đó người dùng chỉ cần đăng ký các dịch vụ và bắt đầu sử dụng nó. Hạn chế chính của thiết lập này là, người ta chỉ có thể thực hiện số lượng tùy chỉnh tối thiểu được nhà cung cấp dịch vụ cho phép. Một trong những ví dụ phổ biến nhất của SaaS là ​​Gmail, nơi người dùng chỉ cần đăng nhập và bắt đầu sử dụng nó. Người dùng cũng có thể thực hiện một số sửa đổi nhỏ đối với tài khoản của mình. Tuy nhiên, nó không hữu ích lắm theo quan điểm của nhà phát triển.

Nền tảng như một dịch vụ (PaaS)

Có thể coi đây là lớp trung gian giữa SaaS và IaaS. Mục tiêu chính của đánh giá PaaS là ​​dành cho các nhà phát triển trong đó môi trường phát triển có thể được tạo ra với một vài lệnh. Các môi trường này được thiết kế theo cách mà chúng có thể thỏa mãn mọi nhu cầu phát triển, ngay từ khi có một máy chủ ứng dụng web với cơ sở dữ liệu. Để làm điều này, bạn chỉ cần một lệnh duy nhất và nhà cung cấp dịch vụ sẽ thực hiện công việc cho bạn.

Tại sao sử dụng OpenShift?

OpenShift cung cấp một nền tảng chung cho các đơn vị doanh nghiệp lưu trữ các ứng dụng của họ trên đám mây mà không cần lo lắng về hệ điều hành bên dưới. Điều này làm cho nó rất dễ sử dụng, phát triển và triển khai các ứng dụng trên đám mây. Một trong những tính năng chính là, nó cung cấp phần cứng được quản lý và tài nguyên mạng cho tất cả các loại phát triển và thử nghiệm. Với OpenShift, nhà phát triển PaaS có quyền tự do thiết kế môi trường yêu cầu của họ với các thông số kỹ thuật.

OpenShift cung cấp các loại thỏa thuận mức dịch vụ khác nhau khi nói đến các gói dịch vụ.

Free - Gói này được giới hạn trong ba năm với dung lượng 1GB cho mỗi gói.

Bronze - Gói này bao gồm 3 năm và mở rộng lên đến 16 năm với dung lượng 1GB mỗi năm.

Sliver - Đây là gói đồng 16 năm, tuy nhiên, có dung lượng lưu trữ 6GB mà không tính thêm phí.

Ngoài các tính năng trên, OpenShift cũng cung cấp phiên bản tại chỗ được gọi là OpenShift Enterprise. Trong OpenShift, các nhà phát triển có đòn bẩy để thiết kế các ứng dụng có thể mở rộng và không thể mở rộng và những thiết kế này được thực hiện bằng cách sử dụng máy chủ HAproxy.

Đặc trưng

Có nhiều tính năng được hỗ trợ bởi OpenShift. Một số ít trong số họ -

  • Hỗ trợ nhiều ngôn ngữ
  • Hỗ trợ nhiều cơ sở dữ liệu
  • Hệ thống hộp mực mở rộng
  • Quản lý phiên bản mã nguồn
  • Triển khai một cú nhấp chuột
  • Hỗ trợ đa môi trường
  • Quy trình làm việc của Nhà phát triển được chuẩn hóa
  • Quản lý phụ thuộc và xây dựng
  • Mở rộng ứng dụng tự động
  • Bảng điều khiển web đáp ứng
  • Bộ công cụ dòng lệnh phong phú
  • Đăng nhập SSH từ xa vào ứng dụng
  • Hỗ trợ API còn lại
  • Ngăn xếp ứng dụng tự phục vụ theo yêu cầu
  • Dịch vụ cơ sở dữ liệu tích hợp
  • Quản lý tích hợp và phát hành liên tục
  • Tích hợp IDE
  • Gỡ lỗi ứng dụng từ xa

OpenShift ra đời từ cơ sở có tên OpenShift V2, chủ yếu dựa trên khái niệm năm và hộp mực, trong đó mỗi thành phần đều có thông số kỹ thuật bắt đầu từ khi tạo máy cho đến khi triển khai ứng dụng, ngay từ khi xây dựng đến triển khai ứng dụng.

Cartridges - Chúng là đầu mối của việc xây dựng một ứng dụng mới bắt đầu từ loại ứng dụng mà môi trường yêu cầu để chạy chúng và tất cả các phụ thuộc được thỏa mãn trong phần này.

year- Nó có thể được định nghĩa là máy hoặc máy chủ bằng kim loại chịu lực với các thông số kỹ thuật nhất định về tài nguyên, bộ nhớ và CPU. Chúng được coi là đơn vị cơ bản để chạy một ứng dụng.

Application - Đây chỉ đơn giản là đề cập đến ứng dụng hoặc bất kỳ ứng dụng tích hợp nào sẽ được triển khai và chạy trên môi trường OpenShift.

Khi đi sâu hơn vào phần này, chúng ta sẽ thảo luận về các định dạng và dịch vụ khác nhau của OpenShift. Trong những ngày trước đó, OpenShift có ba phiên bản chính.

OpenShift Origin- Đây là phần bổ sung cộng đồng hoặc phiên bản nguồn mở của OpenShift. Nó còn được gọi là dự án ngược dòng cho hai phiên bản khác.

OpenShift Online - Đây là một PaaS công khai như một dịch vụ được lưu trữ trên AWS.

OpenShift Enterprise - là phiên bản cứng của OpenShift với ISV và giấy phép của nhà cung cấp.

OpenShift trực tuyến

OpenShift trực tuyến là một sản phẩm của cộng đồng OpenShift sử dụng cộng đồng này có thể nhanh chóng xây dựng, triển khai và mở rộng các ứng dụng được container hóa trên đám mây công cộng. Đây là nền tảng lưu trữ và phát triển ứng dụng đám mây công cộng của Red Hat, cho phép cung cấp, quản lý và mở rộng ứng dụng tự động, giúp nhà phát triển tập trung vào việc viết logic ứng dụng.

Thiết lập tài khoản trên Red Hat OpenShift Online

Step 1 - Vào trình duyệt và truy cập trang web https://manage.openshift.com/

Step 2 - Nếu bạn có tài khoản Red Hat, hãy đăng nhập vào tài khoản OpenShift bằng ID và mật khẩu đăng nhập Red Hat bằng URL sau. https://developers.redhat.com

Step 3 - Nếu bạn chưa đăng nhập tài khoản Red Hat, hãy đăng ký dịch vụ trực tuyến OpenShift bằng liên kết sau.

https://developers.redhat.com/auth/realms/rhd/login-actions/registration?code=G4w-myLd3GCH_QZCqMUmIOQlU7DIf_gfIvGu38nnzZQ.cb229a9d-3cff-4c58-b7f6-7b2c9eb17926

Sau khi đăng nhập, bạn sẽ thấy trang sau.

Khi bạn đã có tất cả mọi thứ, Red Hat sẽ hiển thị một số chi tiết tài khoản cơ bản như được hiển thị trong ảnh chụp màn hình sau.

Cuối cùng, khi bạn đã đăng nhập, bạn sẽ thấy trang sau.

Nền tảng thùng chứa OpenShift

Nền tảng container OpenShift là một nền tảng doanh nghiệp giúp nhiều nhóm như nhóm phát triển và hoạt động CNTT xây dựng và triển khai cơ sở hạ tầng container. Tất cả các vùng chứa được xây dựng trong OpenShift sử dụng công nghệ chứa Docker rất đáng tin cậy, có thể được triển khai trên bất kỳ trung tâm dữ liệu nào của các nền tảng đám mây được lưu trữ công khai.

Nền tảng container OpenShift chính thức được gọi là OpenShift Enterprises. Nó là một nền tảng riêng tư tại chỗ của Red Hat dưới dạng dịch vụ, được xây dựng dựa trên khái niệm cốt lõi về các vùng chứa ứng dụng được cung cấp bởi Docker, nơi mà Kubernetes quản lý điều phối và quản trị.

Nói cách khác, OpenShift mang Docker và Kubernetes lại với nhau ở cấp độ doanh nghiệp. Nó là một phần mềm nền tảng container cho các đơn vị doanh nghiệp triển khai và quản lý các ứng viên trong một cơ sở hạ tầng do chính bạn lựa chọn. Ví dụ: lưu trữ các phiên bản OpenShift trên các phiên bản AWS.

Nền tảng thùng chứa OpenShift có sẵn trong two package levels.

OpenShift Container Local- Điều này dành cho những nhà phát triển muốn triển khai và thử nghiệm các ứng dụng trên máy cục bộ. Gói này chủ yếu được sử dụng bởi các nhóm phát triển để phát triển và thử nghiệm các ứng dụng.

OpenShift Container Lab - Điều này được thiết kế để đánh giá mở rộng ứng dụng bắt đầu từ phát triển cho đến triển khai đến môi trường pre-prod.

OpenShift Dedicated

Đây là một ưu đãi khác được thêm vào danh mục của OpenShift, trong đó khách hàng có thể lựa chọn lưu trữ một nền tảng được container hóa trên bất kỳ đám mây công cộng nào mà họ lựa chọn. Điều này mang lại cho người dùng cuối cảm giác thực sự về cung cấp đa đám mây, nơi họ có thể sử dụng OpenShift trên bất kỳ đám mây nào đáp ứng nhu cầu của họ.

Đây là một trong những ưu đãi mới nhất của Red Hat, nơi người dùng cuối có thể sử dụng OpenShift để xây dựng triển khai thử nghiệm và chạy ứng dụng của họ trên OpenShift được lưu trữ trên đám mây.

Các tính năng của OpenShift Dedicated

OpenShift chuyên cung cấp nền tảng ứng dụng giải pháp tùy chỉnh trên đám mây công cộng và nó được kế thừa từ công nghệ OpenShift 3.

  • Extensible and Open - Điều này được xây dựng dựa trên khái niệm mở của Docker và được triển khai trên đám mây vì nó có thể tự sử dụng khi và khi được yêu cầu.

  • Portability - Vì nó được xây dựng bằng Docker, các ứng dụng chạy trên Docker có thể dễ dàng được vận chuyển từ nơi này đến nơi khác, nơi Docker được hỗ trợ.

  • Orchestration - Với OpenShift 3, một trong những tính năng chính của điều phối vùng chứa và quản lý cụm được hỗ trợ bằng cách sử dụng Kubernetes được cung cấp cùng với OpenShift phiên bản 3.

  • Automation - Phiên bản OpenShift này được kích hoạt với tính năng quản lý mã nguồn, tự động hóa xây dựng và tự động hóa triển khai, điều này làm cho nó rất phổ biến trên thị trường với tư cách là Nhà cung cấp dịch vụ nền tảng.

Đối thủ của OpenShift

Google App Engine- Đây là nền tảng miễn phí của Google để phát triển và lưu trữ các ứng dụng web. Công cụ ứng dụng của Google cung cấp nền tảng triển khai và phát triển nhanh chóng.

Microsoft Azure - Đám mây Azure được Microsoft lưu trữ trên các trung tâm dữ liệu của họ.

Amazon Elastic Cloud Compute - Chúng là các dịch vụ tích hợp do Amazon cung cấp, giúp phát triển và lưu trữ các ứng dụng web có thể mở rộng trên đám mây.

Cloud Foundry - là một nền tảng PaaS mã nguồn mở cho các ứng dụng Java, Ruby, Python và Node.js.

CloudStack - Apache's CloudStack là một dự án được phát triển bởi Citrix và được thiết kế để trở thành đối thủ cạnh tranh trực tiếp của OpenShift và OpenStack.

OpenStack - Một công nghệ đám mây khác do Red Hat cung cấp cho điện toán đám mây.

Kubernetes - Đây là một công nghệ quản lý cụm và điều phối trực tiếp được xây dựng để quản lý vùng chứa Docker.

OpenShift là một hệ thống phân lớp, trong đó mỗi lớp được liên kết chặt chẽ với lớp khác bằng cách sử dụng Kubernetes và cụm Docker. Kiến trúc của OpenShift được thiết kế theo cách mà nó có thể hỗ trợ và quản lý các vùng chứa Docker, được lưu trữ trên tất cả các lớp bằng Kubernetes. Không giống như phiên bản trước đó của OpenShift V2, phiên bản mới của OpenShift V3 hỗ trợ cơ sở hạ tầng được container hóa. Trong mô hình này, Docker giúp tạo các vùng chứa nhẹ dựa trên Linux và Kubernetes hỗ trợ nhiệm vụ sắp xếp và quản lý các vùng chứa trên nhiều máy chủ.

Các thành phần của OpenShift

Một trong những thành phần quan trọng của kiến ​​trúc OpenShift là quản lý cơ sở hạ tầng container trong Kubernetes. Kubernetes chịu trách nhiệm Triển khai và Quản lý cơ sở hạ tầng. Trong bất kỳ cụm Kubernetes nào, chúng ta có thể có nhiều nút chính và nhiều nút, điều này đảm bảo không có điểm nào bị lỗi trong quá trình thiết lập.

Kubernetes Master Machine Linh kiện

Etcd- Nó lưu trữ thông tin cấu hình, có thể được sử dụng bởi từng nút trong cụm. Nó là một kho lưu trữ giá trị khóa có tính khả dụng cao có thể được phân phối giữa nhiều nút. Nó chỉ được truy cập bởi máy chủ Kubernetes API vì nó có thể có thông tin nhạy cảm. Nó là một Kho lưu trữ giá trị khóa phân phối mà tất cả mọi người đều có thể truy cập được.

API Server- Kubernetes là một máy chủ API cung cấp tất cả hoạt động trên cụm bằng cách sử dụng API. Máy chủ API triển khai một giao diện có nghĩa là các công cụ và thư viện khác nhau có thể dễ dàng giao tiếp với nó. Kubeconfig là một gói cùng với các công cụ phía máy chủ có thể được sử dụng để giao tiếp. Nó làm lộ API Kubernetes ”.

Controller Manager- Thành phần này chịu trách nhiệm cho hầu hết các bộ sưu tập điều chỉnh trạng thái của cụm và thực hiện một nhiệm vụ. Nó có thể được coi là một daemon chạy trong một vòng lặp không kết thúc và chịu trách nhiệm thu thập và gửi thông tin đến máy chủ API. Nó hoạt động theo hướng nhận trạng thái được chia sẻ của cụm và sau đó thực hiện các thay đổi để đưa trạng thái hiện tại của máy chủ đến trạng thái mong muốn. Các bộ điều khiển chính là bộ điều khiển sao chép, bộ điều khiển điểm cuối, bộ điều khiển không gian tên và bộ điều khiển tài khoản dịch vụ. Trình quản lý bộ điều khiển chạy các loại bộ điều khiển khác nhau để xử lý các nút, điểm cuối, v.v.

Scheduler- Nó là một thành phần quan trọng của Kubernetes master. Nó là một dịch vụ tổng thể chịu trách nhiệm phân phối khối lượng công việc. Nó chịu trách nhiệm theo dõi việc sử dụng tải làm việc trên các nút cụm và sau đó đặt khối lượng công việc vào tài nguyên nào có sẵn và chấp nhận khối lượng công việc. Nói cách khác, đây là cơ chế chịu trách nhiệm phân bổ nhóm cho các nút có sẵn. Bộ lập lịch chịu trách nhiệm sử dụng khối lượng công việc và phân bổ nhóm cho một nút mới.

Các thành phần nút Kubernetes

Sau đây là các thành phần chính của máy chủ Node, cần thiết để giao tiếp với Kubernetes master.

Docker - Yêu cầu đầu tiên của mỗi nút là Docker giúp chạy các vùng chứa ứng dụng được đóng gói trong một môi trường hoạt động tương đối cô lập nhưng nhẹ.

Kubelet Service- Đây là một dịch vụ nhỏ trong mỗi nút, có nhiệm vụ chuyển tiếp thông tin đến và đi của dịch vụ mặt phẳng điều khiển. Nó tương tác với cửa hàng etcd để đọc chi tiết cấu hình và giá trị Wright. Điều này giao tiếp với thành phần chủ để nhận lệnh và hoạt động. Sau đó, quy trình kubelet đảm nhận trách nhiệm duy trì trạng thái công việc và máy chủ nút. Nó quản lý các quy tắc mạng, chuyển tiếp cổng, v.v.

Kubernetes Proxy Service- Đây là một dịch vụ proxy chạy trên mỗi nút và giúp cung cấp các dịch vụ cho máy chủ bên ngoài. Nó giúp chuyển tiếp yêu cầu sửa vùng chứa. Kubernetes Proxy Service có khả năng thực hiện cân bằng tải nguyên thủy. Nó đảm bảo rằng môi trường mạng có thể dự đoán được và có thể truy cập được nhưng đồng thời nó cũng bị cô lập. Nó quản lý các nhóm trên nút, khối lượng, bí mật, tạo kiểm tra sức khỏe vùng chứa mới, v.v.

Tích hợp OpenShift Container Registry

Đăng ký vùng chứa OpenShift là một đơn vị lưu trữ sẵn có của Red Hat, được sử dụng để lưu trữ hình ảnh Docker. Với phiên bản tích hợp mới nhất của OpenShift, nó đã đi kèm với giao diện người dùng để xem hình ảnh trong bộ nhớ trong của OpenShift. Các cơ quan đăng ký này có khả năng lưu giữ hình ảnh với các thẻ được chỉ định, sau này được sử dụng để xây dựng các vùng chứa từ nó.

Điều khoản thường dùng

Image- Hình ảnh Kubernetes (Docker) là các khối xây dựng chính của Cơ sở hạ tầng được chứa đựng. Hiện tại, Kubernetes chỉ hỗ trợ hình ảnh Docker. Mỗi vùng chứa trong một nhóm có hình ảnh Docker của nó chạy bên trong nó. Khi định cấu hình một nhóm, thuộc tính hình ảnh trong tệp cấu hình có cùng cú pháp với lệnh Docker.

Project - Chúng có thể được định nghĩa là phiên bản được đổi tên của miền đã có trong phiên bản OpenShift V2 trước đó.

Container - Chúng là những cái được tạo sau khi hình ảnh được triển khai trên một nút cụm Kubernetes.

Node- Một nút là một máy làm việc trong Kubernetes cluster, còn được gọi là minion cho master. Chúng là các đơn vị làm việc có thể là một phiên bản vật lý, máy ảo hoặc đám mây.

Pod- Một nhóm là một tập hợp các vùng chứa và bộ lưu trữ của nó bên trong một nút của một cụm Kubernetes. Có thể tạo một nhóm với nhiều vùng chứa bên trong nó. Ví dụ: giữ vùng chứa cơ sở dữ liệu và vùng chứa máy chủ web bên trong nhóm.

Trong chương này, chúng ta sẽ tìm hiểu về thiết lập môi trường của OpenShift.

Yêu cầu hệ thống

Để thiết lập OpenShift doanh nghiệp, người ta cần có tài khoản Red Hat đang hoạt động. Vì OpenShift hoạt động trên kiến ​​trúc nút và chủ Kubernetes, chúng ta cần thiết lập cả hai trên các máy riêng biệt, trong đó một máy hoạt động như một máy chủ và các máy khác hoạt động trên nút. Để thiết lập cả hai, cần có các yêu cầu hệ thống tối thiểu.

Cấu hình máy chính

Sau đây là các yêu cầu hệ thống tối thiểu cho cấu hình máy chủ.

  • Máy cơ sở được lưu trữ trên vật lý, ảo hoặc trên bất kỳ môi trường đám mây nào.

  • Ít nhất là Linux 7 với các gói bắt buộc trên phiên bản đó.

  • 2 nhân CPU.

  • RAM ít nhất 8 GB.

  • Bộ nhớ đĩa cứng bên trong 30 GB.

Cấu hình máy nút

  • Hình ảnh cơ sở vật lý hoặc ảo được cung cấp cho máy chủ.
  • Có ít nhất Linux 7 trên máy.
  • Docker được cài đặt với phiên bản không dưới 1.6.
  • 1 nhân CPU.
  • RAM 8 GB.
  • Đĩa cứng 15 GB để lưu trữ hình ảnh và 15 GB để lưu trữ hình ảnh.

Hướng dẫn từng bước để thiết lập OpenShift

Trong mô tả sau đây, chúng ta sẽ thiết lập môi trường phòng thí nghiệm OpenShift, sau này có thể được mở rộng thành một cụm lớn hơn. Vì OpenShift yêu cầu thiết lập nút và máy chủ, chúng tôi sẽ cần ít nhất hai máy được lưu trữ trên đám mây, máy vật lý hoặc máy ảo.

Step 1- Đầu tiên hãy cài đặt Linux trên cả hai máy, trong đó Linux 7 nên là phiên bản ít nhất. Điều này có thể được thực hiện bằng cách sử dụng các lệnh sau nếu một người có đăng ký Red Hat đang hoạt động.

# subscription-manager repos --disable = "*"

# subscription-manager repos --enable = "rhel-7-server-rpms"

# subscription-manager repos --enable = "rhel-7-server-extras-rpms"

# subscription-manager repos --enable = "rhel-7-server-optional-rpms"

# subscription-manager repos --enable = "rhel-7-server-ose-3.0-rpms"

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install python-virtualenv

# yum install gcc

# yum install httpd-tools

# yum install docker

# yum update

Khi chúng ta đã cài đặt tất cả các gói cơ sở trên trong cả hai máy, bước tiếp theo sẽ là thiết lập Docker trên các máy tương ứng.

Step 2- Định cấu hình Docker để nó chỉ cho phép giao tiếp không an toàn trên mạng cục bộ. Đối với điều này, hãy chỉnh sửa tệp Docker bên trong / etc / sysconfig. Nếu tệp không có thì bạn cần phải tạo nó theo cách thủ công.

# vi /etc/sysconfig/docker
OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24

Sau khi định cấu hình Docker trên máy chủ, chúng ta cần thiết lập giao tiếp không cần mật khẩu giữa cả hai máy. Đối với điều này, chúng tôi sẽ sử dụng xác thực khóa công khai và riêng tư.

Step 3 - Tạo khóa trên máy chủ và sau đó sao chép khóa id_rsa.pub vào tệp khóa được ủy quyền của máy nút, có thể thực hiện bằng lệnh sau.

# ssh-keygen

# ssh-copy-id -i .ssh/id_rsa.pub [email protected]

Khi bạn đã có tất cả các thiết lập trên, tiếp theo là thiết lập OpenShift phiên bản 3 trên máy chủ.

Step 4 - Từ máy chủ, chạy lệnh curl sau.

# sh <(curl -s https://install.openshift.com/ose)

Lệnh trên sẽ đặt thiết lập cho OSV3. Bước tiếp theo sẽ là cấu hình OpenShift V3 trên máy.

Nếu bạn không thể tải xuống trực tiếp từ Internet, thì có thể tải xuống từ https://install.openshift.com/portable/oo-install-ose.tgz dưới dạng gói tar mà từ đó trình cài đặt có thể chạy trên máy chủ cục bộ.

Khi đã thiết lập xong, chúng ta cần bắt đầu với cấu hình thực của OSV3 trên máy. Thiết lập này rất cụ thể để kiểm tra môi trường cho quá trình sản xuất thực tế, chúng tôi có sẵn LDAP và những thứ khác.

Step 5 - Trên máy chủ, định cấu hình mã sau nằm trong /etc/openshift/master/master-config.yaml

# vi /etc/openshift/master/master-config.yaml
identityProviders:
- name: my_htpasswd_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /root/users.htpasswd
routingConfig:
subdomain: testing.com

Tiếp theo, tạo một người dùng tiêu chuẩn để quản trị mặc định.

# htpasswd -c /root/users.htpasswd admin

Step 6- Vì OpenShift sử dụng sổ đăng ký Docker để định cấu hình hình ảnh, chúng tôi cần cấu hình sổ đăng ký Docker. Điều này được sử dụng để tạo và lưu trữ các hình ảnh Docker sau khi xây dựng.

Tạo một thư mục trên máy nút OpenShift bằng lệnh sau.

# mkdir /images

Tiếp theo, đăng nhập vào máy chủ bằng thông tin đăng nhập quản trị viên mặc định, được tạo trong khi thiết lập sổ đăng ký.

# oc login
Username: system:admin

Chuyển sang dự án được tạo mặc định.

# oc project default

Step 7 - Tạo một Docker Registry.

#echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"registry"}}' | oc create -f -

Chỉnh sửa các đặc quyền của người dùng.

#oc edit scc privileged
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:registry

Tạo và chỉnh sửa sổ đăng ký hình ảnh.

#oadm registry --service-account = registry --
config = /etc/openshift/master/admin.kubeconfig --
credentials = /etc/openshift/master/openshift-registry.kubeconfig --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' --
mount-host = /images

Step 8 - Tạo một định tuyến mặc định.

Theo mặc định, OpenShift sử dụng OpenVswitch làm mạng phần mềm. Sử dụng lệnh sau để tạo định tuyến mặc định. Điều này được sử dụng để cân bằng tải và định tuyến proxy. Bộ định tuyến tương tự như sổ đăng ký Docker và cũng chạy trong sổ đăng ký.

# echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"router"}}' | oc create -f -

Tiếp theo, chỉnh sửa các đặc quyền của người dùng.

#oc edit scc privileged
users:
   - system:serviceaccount:openshift-infra:build-controller
   - system:serviceaccount:default:registry
   - system:serviceaccount:default:router

#oadm router router-1 --replicas = 1 --
credentials = '/etc/openshift/master/openshift-router.kubeconfig' --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}'

Step 9 - Cấu hình DNS.

Để xử lý yêu cầu URL, OpenShift cần một môi trường DNS hoạt động. Cấu hình DNS này được yêu cầu để tạo thẻ đại diện, thẻ này được yêu cầu để tạo thẻ đại diện DNS trỏ đến bộ định tuyến.

# yum install bind-utils bind

# systemctl start named

# systemctl enable named

vi /etc/named.conf
options {listen-on port 53 { 10.123.55.111; };
forwarders {
   10.38.55.13;
   ;
};

zone "lab.com" IN {
   type master;
   file "/var/named/dynamic/test.com.zone";
   allow-update { none; };
};

Step 10- Bước cuối cùng sẽ là thiết lập máy chủ github trên máy chủ OpenShift V3, đây là tùy chọn. Điều này có thể được thực hiện dễ dàng bằng cách sử dụng chuỗi lệnh sau.

#yum install curl openssh-server

#systemctl enable sshd

# systemctl start sshd

# firewall-cmd --permanent --add-service = http

# systemctl reload firewalld

#curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-

#yum install gitlab-ce

# gitlab-ctl reconfigure

Khi quá trình thiết lập ở trên hoàn tất, bạn có thể xác minh bằng cách kiểm tra và triển khai các ứng dụng, điều này chúng ta sẽ biết thêm trong các chương tiếp theo.

Trước khi bắt đầu thiết lập và triển khai ứng dụng thực tế, chúng ta cần hiểu một số thuật ngữ và khái niệm cơ bản được sử dụng trong OpenShift V3.

Vùng chứa và Hình ảnh

Hình ảnh

Đây là các khối xây dựng cơ bản của OpenShift, được hình thành từ các hình ảnh Docker. Trong mỗi nhóm trên OpenShift, cụm có các hình ảnh riêng chạy bên trong nó. Khi chúng tôi định cấu hình một nhóm, chúng tôi có một trường sẽ được gộp chung từ sổ đăng ký. Tệp cấu hình này sẽ kéo hình ảnh và triển khai nó trên nút cụm.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> Name of Pod
      spec:
containers:
- name: neo4j-server ------------------------> Name of the image
image: <Name of the Docker image>----------> Image to be pulled
imagePullPolicy: Always ------------->Image pull policy
command: [“echo”, “SUCCESS”] -------------------> Massage after image pull

Để kéo và tạo một hình ảnh từ nó, hãy chạy lệnh sau. OC là máy khách để giao tiếp với môi trường OpenShift sau khi đăng nhập.

$ oc create –f Tesing_for_Image_pull

Thùng đựng hàng

Điều này được tạo khi hình ảnh Docker được triển khai trên cụm OpenShift. Trong khi xác định bất kỳ cấu hình nào, chúng tôi xác định phần vùng chứa trong tệp cấu hình. Một vùng chứa có thể có nhiều hình ảnh chạy bên trong và tất cả các vùng chứa chạy trên nút cụm đều được OpenShift Kubernetes quản lý.

spec:
   containers:
   - name: py ------------------------> Name of the container
   image: python----------> Image going to get deployed on container
   command: [“python”, “SUCCESS”]
   restartPocliy: Never --------> Restart policy of container

Sau đây là các thông số kỹ thuật để xác định một vùng chứa có nhiều hình ảnh chạy bên trong nó.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
   - containerPort: 7500
      imagePullPolicy: Always
      -name: Database
      Image: mongoDB
      Ports:
      - containerPort: 7501
imagePullPolicy: Always

Trong cấu hình trên, chúng tôi đã xác định một nhóm đa vùng chứa với hai hình ảnh Tomcat và MongoDB bên trong nó.

Nhóm và Dịch vụ

Vỏ

Pod có thể được định nghĩa là một tập hợp các vùng chứa và lưu trữ của nó bên trong một nút của cụm OpenShift (Kubernetes). Nói chung, chúng ta có hai loại nhóm bắt đầu từ một nhóm chứa một thùng chứa đến nhóm nhiều thùng chứa.

Single Container Pod - Chúng có thể được tạo dễ dàng bằng lệnh OC hoặc bằng tệp yml cấu hình cơ bản.

$ oc run <name of pod> --image = <name of the image from registry>

Tạo nó bằng một tệp yaml đơn giản như sau.

apiVersion: v1
kind: Pod
metadata:
   name: apache
spec:
   containers:
   - name: apache
   image: apache: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always

Khi tệp trên được tạo, nó sẽ tạo một nhóm bằng lệnh sau.

$ oc create –f apache.yml

Multi-Container Pod- Vỏ nhiều vùng chứa là những vỏ mà chúng ta có nhiều hơn một vùng chứa chạy bên trong nó. Chúng được tạo bằng các tệp yaml như sau.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
      - containerPort: 7501
imagePullPolicy: Always

Sau khi tạo các tệp này, chúng ta chỉ cần sử dụng phương pháp tương tự như trên để tạo vùng chứa.

Service- Khi chúng ta có một tập hợp các vùng chứa chạy bên trong một nhóm, theo cách tương tự, chúng ta có một dịch vụ có thể được định nghĩa là một tập hợp các nhóm hợp lý. Đó là một lớp được trừu tượng hóa trên đầu nhóm, cung cấp một IP và tên DNS duy nhất mà thông qua đó, các nhóm có thể được truy cập. Dịch vụ giúp quản lý cấu hình cân bằng tải và chia tỷ lệ nhóm rất dễ dàng. Trong OpenShift, một dịch vụ là một đối tượng REST mà định danh của nó có thể được đăng lên apiService trên OpenShift master để tạo một phiên bản mới.

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
      - port: 8080
         targetPort: 31999

Công trình và Luồng

Công trình

Trong OpenShift, xây dựng là một quá trình chuyển đổi hình ảnh thành các vùng chứa. Đây là quá trình chuyển đổi mã nguồn thành hình ảnh. Quá trình xây dựng này hoạt động dựa trên chiến lược xây dựng mã nguồn thành hình ảnh được xác định trước.

Quá trình xây dựng nhiều chiến lược và nguồn.

Xây dựng chiến lược

  • Source to Image- Về cơ bản, đây là một công cụ giúp xây dựng hình ảnh có thể tái tạo. Những hình ảnh này luôn ở trong giai đoạn sẵn sàng chạy bằng lệnh Docker run.

  • Docker Build - Đây là quá trình hình ảnh được tạo bằng tệp Docker bằng cách chạy lệnh xây dựng Docker đơn giản.

  • Custom Build - Đây là các bản dựng được sử dụng để tạo hình ảnh Docker cơ sở.

Tạo nguồn

Git- Nguồn này được sử dụng khi kho lưu trữ git được sử dụng để xây dựng hình ảnh. Dockerfile là tùy chọn. Các cấu hình từ mã nguồn trông giống như sau.

source:
type: "Git"
git:
   uri: "https://github.com/vipin/testing.git"
   ref: "master"
contextDir: "app/dir"
dockerfile: "FROM openshift/ruby-22-centos7\nUSER example"

Dockerfile - Dockerfile được sử dụng như một đầu vào trong tệp cấu hình.

source:
   type: "Dockerfile"
   dockerfile: "FROM ubuntu: latest
   RUN yum install -y httpd"

Image Streams- Các luồng ảnh được tạo ra sau khi kéo ảnh. Ưu điểm của luồng hình ảnh là nó tìm kiếm các bản cập nhật về phiên bản mới của hình ảnh. Điều này được sử dụng để so sánh bất kỳ số lượng hình ảnh vùng chứa có định dạng Docker nào được xác định bằng thẻ.

Luồng hình ảnh có thể tự động thực hiện một hành động khi một hình ảnh mới được tạo. Tất cả các bản dựng và triển khai có thể theo dõi hành động của hình ảnh và thực hiện hành động tương ứng. Sau đây là cách chúng tôi xác định một luồng xây dựng.

apiVersion: v1
kind: ImageStream
metadata:
   annotations:
      openshift.io/generated-by: OpenShiftNewApp
   generation: 1
   labels:
      app: ruby-sample-build
   selflink: /oapi/v1/namespaces/test/imagestreams/origin-ruby-sample
   uid: ee2b9405-c68c-11e5-8a99-525400f25e34
spec: {}
status:
   dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample
   tags:
   - items:
      - created: 2016-01-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-apache-sample
      generation: 1
      image: vklnld908.int.clsa.com/vipin/test
   tag: latest

Định tuyến và Mẫu

Các tuyến đường

Trong OpenShift, định tuyến là một phương pháp hiển thị dịch vụ với thế giới bên ngoài bằng cách tạo và định cấu hình tên máy chủ có thể truy cập bên ngoài. Các tuyến và điểm cuối được sử dụng để hiển thị dịch vụ với thế giới bên ngoài, từ đó người dùng có thể sử dụng kết nối tên (DNS) để truy cập ứng dụng đã xác định.

Trong OpenShift, các tuyến đường được tạo bằng cách sử dụng các bộ định tuyến do quản trị viên OpenShift triển khai trên cụm. Bộ định tuyến được sử dụng để liên kết các cổng HTTP (80) và https (443) với các ứng dụng bên ngoài.

Sau đây là các loại giao thức khác nhau được hỗ trợ bởi các tuyến đường:

  • HTTP
  • HTTPS
  • TSL và ổ cắm web

Khi cấu hình dịch vụ, các bộ chọn được sử dụng để cấu hình dịch vụ và tìm điểm cuối bằng dịch vụ đó. Sau đây là một ví dụ về cách chúng tôi tạo một dịch vụ và định tuyến cho dịch vụ đó bằng cách sử dụng một giao thức thích hợp.

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-Rservice"},
   "spec": {
      "selector": {"name":"RService-openshift"},
      "ports": [
         {
            "protocol": "TCP",
            "port": 8888,
            "targetPort": 8080
         }
      ]
   }
}

Tiếp theo, chạy lệnh sau và dịch vụ được tạo.

$ oc create -f ~/training/content/Openshift-Rservice.json

Đây là cách dịch vụ trông như thế nào sau khi tạo.

$ oc describe service Openshift-Rservice

Name:              Openshift-Rservice
Labels:            <none>
Selector:          name = RService-openshift
Type:              ClusterIP
IP:                172.30.42.80
Port:              <unnamed> 8080/TCP
Endpoints:         <none>
Session Affinity:  None
No events.

Tạo định tuyến cho dịch vụ bằng đoạn mã sau.

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-service-route"},
   "spec": {
      "host": "hello-openshift.cloudapps.example.com",
      "to": {
         "kind": "Service",
         "name": "OpenShift-route-service"
      },
      "tls": {"termination": "edge"}
   }
}

Khi lệnh OC được sử dụng để tạo một tuyến, một phiên bản mới của tài nguyên tuyến sẽ được tạo.

Mẫu

Các mẫu được định nghĩa là một đối tượng tiêu chuẩn trong OpenShift có thể được sử dụng nhiều lần. Nó được tham số hóa với danh sách các trình giữ chỗ được sử dụng để tạo nhiều đối tượng. Điều này có thể được sử dụng để tạo bất kỳ thứ gì, bắt đầu từ nhóm đến mạng mà người dùng có quyền tạo. Danh sách các đối tượng có thể được tạo, nếu mẫu từ giao diện CLI hoặc GUI trong hình ảnh được tải lên thư mục dự án.

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

Xác thực và Ủy quyền

Xác thực

Trong OpenShift, trong khi định cấu hình chính và cấu trúc máy khách, chủ đưa ra một tính năng có sẵn của máy chủ OAuth. Máy chủ OAuth được sử dụng để tạo mã thông báo, được sử dụng để xác thực API. Vì OAuth xuất hiện dưới dạng thiết lập mặc định cho chính, chúng tôi có Cho phép tất cả nhà cung cấp danh tính được sử dụng theo mặc định. Các nhà cung cấp danh tính khác nhau hiện diện có thể được định cấu hình tại/etc/openshift/master/master-config.yaml.

Có nhiều loại nhà cung cấp danh tính khác nhau hiện diện trong OAuth.

  • Chấp nhận tất cả
  • Phủ nhận tất cả
  • HTPasswd
  • LDAP
  • Xác thực cơ bản

Chấp nhận tất cả

apiVersion: v1
   kind: Pod
   metadata:
      name: redis-master
   spec:
      containers:
         image: dockerfile/redis
         name: master
      ports:
      - containerPort: 6379
         protocol: TCP
      oauthConfig:
      identityProviders:
      - name: my_allow_provider
         challenge: true
         login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Phủ nhận tất cả

apiVersion: v1
kind: Pod
metadata:
   name: redis-master
spec:
   containers:
      image: dockerfile/redis
   name: master
   ports:
   - containerPort: 6379
      protocol: TCP
   oauthConfig:
   identityProviders:
   - name: my_allow_provider
      challenge: true
      login: true
   provider:
      apiVersion: v1
      kind: DenyAllPasswordIdentityProvider

HTPasswd

Để sử dụng HTPasswd, trước tiên chúng ta cần thiết lập Httpd-tools trên máy chủ và sau đó cấu hình nó theo cách tương tự như chúng ta đã làm cho những người khác.

identityProviders:
   - name: my_htpasswd_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider

Ủy quyền

Ủy quyền là một tính năng của OpenShift master, được sử dụng để xác nhận việc xác thực người dùng. Điều này có nghĩa là nó kiểm tra người dùng đang cố gắng thực hiện một hành động để xem liệu người dùng có được phép thực hiện hành động đó trên một dự án nhất định hay không. Điều này giúp quản trị viên kiểm soát quyền truy cập vào các dự án.

Chính sách ủy quyền được kiểm soát bằng cách sử dụng -

  • Rules
  • Roles
  • Bindings

Đánh giá ủy quyền được thực hiện bằng cách sử dụng -

  • Identity
  • Action
  • Bindings

Sử dụng chính sách -

  • Chính sách cụm
  • Chính sách địa phương

OpenShift bao gồm hai loại phương tiện để tạo và triển khai ứng dụng, bằng GUI hoặc bằng CLI. Trong chương này, chúng ta sẽ sử dụng CLI để tạo một ứng dụng mới. Chúng tôi sẽ sử dụng ứng dụng khách OC để giao tiếp với môi trường OpenShift.

Tạo ứng dụng mới

Trong OpenShift, có ba phương pháp tạo một ứng dụng mới.

  • Từ một mã nguồn
  • Từ một hình ảnh
  • Từ một mẫu

Từ mã nguồn

Khi chúng tôi cố gắng tạo một ứng dụng từ mã nguồn, OpenShift sẽ tìm kiếm một tệp Docker sẽ có bên trong repo, tệp này xác định quy trình xây dựng ứng dụng. Chúng tôi sẽ sử dụng ứng dụng mới oc để tạo ứng dụng.

Điều đầu tiên cần ghi nhớ khi sử dụng repo là nó phải trỏ đến một nguồn gốc trong repo từ đó OpenShift sẽ kéo mã và xây dựng nó.

Nếu repo được sao chép trên máy Docker, nơi OC client được cài đặt và người dùng đang ở trong cùng một thư mục, thì nó có thể được tạo bằng lệnh sau.

$ oc new-app . <Hear. Denotes current working directory>

Sau đây là một ví dụ về việc cố gắng xây dựng từ kho lưu trữ từ xa cho một nhánh cụ thể.

$ oc new-app https://github.com/openshift/Testing-deployment.git#test1

Ở đây, test1 là nhánh mà chúng tôi đang cố gắng tạo một ứng dụng mới trong OpenShift.

Khi chỉ định tệp Docker trong kho, chúng ta cần xác định chiến lược xây dựng như hình dưới đây.

$ oc new-app OpenShift/OpenShift-test~https://github.com/openshift/Testingdeployment.git

Từ một hình ảnh

Trong khi xây dựng ứng dụng bằng hình ảnh, hình ảnh hiện diện trong máy chủ Docker cục bộ, trong kho lưu trữ Docker được lưu trữ nội bộ hoặc trên trung tâm Docker. Điều duy nhất mà người dùng cần đảm bảo là anh ta có quyền truy cập để lấy hình ảnh từ trung tâm mà không gặp vấn đề gì.

OpenShift có khả năng xác định nguồn được sử dụng, cho dù đó là hình ảnh Docker hay một luồng nguồn. Tuy nhiên, nếu người dùng muốn, anh ta có thể xác định rõ ràng đó là luồng hình ảnh hay hình ảnh Docker.

$ oc new-app - - docker-image tomcat

Sử dụng luồng hình ảnh -

$ oc new-app tomcat:v1

Từ một mẫu

Mẫu có thể được sử dụng để tạo một ứng dụng mới. Nó có thể là một mẫu đã có sẵn hoặc tạo một mẫu mới.

Tệp sau yaml về cơ bản là một mẫu có thể được sử dụng để triển khai.

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

Phát triển và triển khai ứng dụng web

Phát triển một ứng dụng mới trong OpenShift

Để tạo một ứng dụng mới trong OpenShift, chúng ta phải viết một mã ứng dụng mới và xây dựng nó bằng các lệnh xây dựng OpenShift OC. Như đã thảo luận, chúng ta có nhiều cách để tạo một hình ảnh mới. Ở đây, chúng tôi sẽ sử dụng một mẫu để xây dựng ứng dụng. Mẫu này sẽ tạo một ứng dụng mới khi chạy bằng lệnh oc new-app.

Mẫu sau sẽ tạo - Hai ứng dụng front-end và một cơ sở dữ liệu. Cùng với đó, nó sẽ tạo ra hai dịch vụ mới và các ứng dụng đó sẽ được triển khai vào cụm OpenShift. Trong khi xây dựng và triển khai một ứng dụng, ban đầu chúng ta cần tạo một không gian tên trong OpenShift và triển khai ứng dụng dưới không gian tên đó.

Create a new namespace

$ oc new-project openshift-test --display-name = "OpenShift 3 Sample" --
description = "This is an example project to demonstrate OpenShift v3"

Bản mẫu

{
   "kind": "Template",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-helloworld-sample",
      "creationTimestamp": null,
         "annotations": {
         "description": "This example shows how to create a simple openshift
         application in openshift origin v3",
         "iconClass": "icon-openshift",
         "tags": "instant-app,openshift,mysql"
      }
   }
},

Định nghĩa đối tượng

Secret definition in a template

"objects": [
{
   "kind": "Secret",
   "apiVersion": "v1",
   "metadata": {"name": "dbsecret"},
   "stringData" : {
      "mysql-user" : "${MYSQL_USER}",
      "mysql-password" : "${MYSQL_PASSWORD}"
   }
},

Service definition in a template

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   },
   "spec": {
      "ports": [
         {
            "name": "web",
            "protocol": "TCP",
            "port": 5432,
            "targetPort": 8080,
            "nodePort": 0
         }
      ],
      "selector": {"name": "frontend"},
      "type": "ClusterIP",
      "sessionAffinity": "None"
   },
   "status": {
      "loadBalancer": {}
   }
},

Route definition in a template

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {
      "name": "route-edge",
      "creationTimestamp": null,
      "annotations": {
         "template.openshift.io/expose-uri": "http://{.spec.host}{.spec.path}"
      }
   },
   "spec": {
      "host": "www.example.com",
      "to": {
         "kind": "Service",
         "name": "frontend"
      },
      "tls": {
         "termination": "edge"
      }
   },
   "status": {}
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "origin-openshift-sample",
      "creationTimestamp": null
   },
   "spec": {},
   "status": {
      "dockerImageRepository": ""
   }
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-22-ubuntu7",
      "creationTimestamp": null 
   },
   "spec": {
      "dockerImageRepository": "ubuntu/openshift-22-ubuntu7"
   },
   "status": {
      "dockerImageRepository": ""
   }
},

Build config definition in a template

{
   "kind": "BuildConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-sample-build",
      "creationTimestamp": null,
      "labels": {name": "openshift-sample-build"}
   },
   "spec": {
      "triggers": [
         { "type": "GitHub",
            "github": {
            "secret": "secret101" } 
         },
         {
            "type": "Generic",
            "generic": {
               "secret": "secret101",
               "allowEnv": true } 
         },
         { 
            "type": "ImageChange",
            "imageChange": {} 
         },
         { "type": "ConfigChange”}
      ],
      "source": {
         "type": "Git",
         "git": {
            "uri": https://github.com/openshift/openshift-hello-world.git } 
      },
      "strategy": {
         "type": "Docker",
         "dockerStrategy": {
            "from": {
               "kind": "ImageStreamTag",
               "name": "openshift-22-ubuntu7:latest” 
            },
            "env": [
               {
                  "name": "EXAMPLE",
                  "value": "sample-app"
               } 
            ]
         }
      },
      "output": {
         "to": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      },
      "postCommit": {
         "args": ["bundle", "exec", "rake", "test"]
      },
      "status": {
         "lastVersion": 0
      }
   }
},

Deployment config in a template

"status": {
   "lastVersion": 0
}
{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   }
}, 
"spec": {
   "strategy": {
      "type": "Rolling",
      "rollingParams": {
         "updatePeriodSeconds": 1,
         "intervalSeconds": 1,
         "timeoutSeconds": 120,
         "pre": {
            "failurePolicy": "Abort",
            "execNewPod": {
               "command": [
                  "/bin/true"
               ],
               "env": [
                  { 
                     "name": "CUSTOM_VAR1",
                     "value": "custom_value1"
                  }
               ]
            }
         }
      }
   }
}
"triggers": [
   {
      "type": "ImageChange",
      "imageChangeParams": {
         "automatic": true,
         "containerNames": [
            "openshift-helloworld"
         ],
         "from": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      }
   },
   {
      "type": "ConfigChange"
   }
],
"replicas": 2,
"selector": {
   "name": "frontend"
},
"template": {
   "metadata": {
      "creationTimestamp": null,
      "labels": {
         "name": "frontend"
      }
   },
   "spec": {
      "containers": [
         {
            "name": "openshift-helloworld",
            "image": "origin-openshift-sample",
            "ports": [
               { 
                  "containerPort": 8080,
                  "protocol": "TCP” 
               }
            ],
            "env": [
               {
                  "name": "MYSQL_USER",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-user"
                     }
                  }
               },
               {
                  "name": "MYSQL_PASSWORD",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-password"
                     }
                  }
               },
               {
                  "name": "MYSQL_DATABASE",
                  "value": "${MYSQL_DATABASE}"
               }
            ],
            "resources": {},
            "terminationMessagePath": "/dev/termination-log",
            "imagePullPolicy": "IfNotPresent",
            "securityContext": {
               "capabilities": {},
               "privileged": false
            }
         }
      ],
      "restartPolicy": "Always",
      "dnsPolicy": "ClusterFirst"
   },
   "status": {}
},

Service definition in a template

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null 
   },
   "spec": {
   "ports": [
      {
         "name": "db",
         "protocol": "TCP",
         "port": 5434,
         "targetPort": 3306,
         "nodePort": 0
      } 
   ],
   "selector": {
      "name": "database 
   },
   "type": "ClusterIP",
   "sessionAffinity": "None" },
   "status": {
      "loadBalancer": {}
   }
},

Deployment config definition in a template

{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null
   },
   "spec": {
      "strategy": {
         "type": "Recreate",
         "resources": {}
      },
      "triggers": [
         {
            "type": "ConfigChange"
         }
      ],
      "replicas": 1,
      "selector": {"name": "database"},
      "template": {
         "metadata": {
            "creationTimestamp": null,
            "labels": {"name": "database"}
         },
         "template": {
            "metadata": {
               "creationTimestamp": null,
               "labels": {
                  "name": "database"
               } 
            },
            "spec": {
               "containers": [
                  {
                     "name": "openshift-helloworld-database",
                     "image": "ubuntu/mysql-57-ubuntu7:latest",
                     "ports": [
                        {
                           "containerPort": 3306,
                           "protocol": "TCP" 
                        }
                     ],
                     "env": [
                        {
                           "name": "MYSQL_USER",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-user"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_PASSWORD",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-password"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_DATABASE",
                           "value": "${MYSQL_DATABASE}" 
                        } 
                     ],
                     "resources": {},
                     "volumeMounts": [
                        {
                           "name": "openshift-helloworld-data",
                           "mountPath": "/var/lib/mysql/data"
                        }
                     ],
                     "terminationMessagePath": "/dev/termination-log",
                     "imagePullPolicy": "Always",
                     "securityContext": {
                        "capabilities": {},
                        "privileged": false
                     } 
                  }
               ],
               "volumes": [
                  { 
                     "name": "openshift-helloworld-data",
                     "emptyDir": {"medium": ""} 
                  } 
               ],
               "restartPolicy": "Always",
               "dnsPolicy": "ClusterFirst” 
            } 
         }
      },
      "status": {} 
   },
   "parameters": [
      { 
         "name": "MYSQL_USER",
         "description": "database username",
         "generate": "expression",
         "from": "user[A-Z0-9]{3}",
         "required": true 
      },
      {
         "name": "MYSQL_PASSWORD",
         "description": "database password",
         "generate": "expression",
         "from": "[a-zA-Z0-9]{8}",
         "required": true
      }, 
      {
         "name": "MYSQL_DATABASE",
         "description": "database name",
         "value": "root",
         "required": true 
      } 
   ],
   "labels": {
      "template": "application-template-dockerbuild" 
   } 
}

Tệp mẫu trên cần được biên dịch cùng một lúc. Trước tiên, chúng ta cần sao chép tất cả nội dung vào một tệp duy nhất và đặt tên là tệp yaml sau khi hoàn tất.

Chúng ta cần chạy lệnh sau để tạo ứng dụng.

$ oc new-app application-template-stibuild.json
--> Deploying template openshift-helloworld-sample for "application-template-stibuild.json"

   openshift-helloworld-sample
   ---------
   This example shows how to create a simple ruby application in openshift origin v3
   * With parameters:
      * MYSQL_USER = userPJJ # generated
      * MYSQL_PASSWORD = cJHNK3se # generated
      * MYSQL_DATABASE = root

--> Creating resources with label app = ruby-helloworld-sample ...
   service "frontend" created
   route "route-edge" created
   imagestream "origin-ruby-sample" created
   imagestream "ruby-22-centos7" created
   buildconfig "ruby-sample-build" created
   deploymentconfig "frontend" created
   service "database" created
   deploymentconfig "database" created
   
--> Success
   Build scheduled, use 'oc logs -f bc/ruby-sample-build' to track its progress.
   Run 'oc status' to view your app.

Nếu chúng ta muốn giám sát việc xây dựng, nó có thể được thực hiện bằng cách sử dụng -

$ oc get builds

NAME                        TYPE      FROM          STATUS     STARTED         DURATION
openshift-sample-build-1    Source   Git@bd94cbb    Running    7 seconds ago   7s

Chúng tôi có thể kiểm tra các ứng dụng đã triển khai trên OpenShift bằng cách sử dụng -

$ oc get pods
NAME                            READY   STATUS      RESTARTS   AGE
database-1-le4wx                1/1     Running     0          1m
frontend-1-e572n                1/1     Running     0          27s
frontend-1-votq4                1/1     Running     0          31s
opeshift-sample-build-1-build   0/1     Completed   0          1m

Chúng tôi có thể kiểm tra xem các dịch vụ ứng dụng có được tạo theo định nghĩa dịch vụ hay không bằng cách sử dụng

$ oc get services
NAME        CLUSTER-IP      EXTERNAL-IP     PORT(S)      SELECTOR          AGE
database    172.30.80.39    <none>         5434/TCP     name=database      1m
frontend    172.30.17.4     <none>         5432/TCP     name=frontend      1m

Trong OpenShift, chúng tôi có nhiều phương pháp tự động hóa quá trình xây dựng. Để làm được điều đó, chúng ta cần tạo một tài nguyên BuildConfig để mô tả luồng xây dựng. Luồng trong BuildConfig có thể được so sánh với định nghĩa công việc trong định nghĩa công việc của Jenkins. Trong khi tạo luồng xây dựng, chúng ta phải chọn chiến lược xây dựng.

Tệp BuildConfig

Trong OpenShift, BuildConfig là một đối tượng còn lại được sử dụng để kết nối với API và sau đó tạo một phiên bản mới.

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "<Name of build config file>"
spec:
   runPolicy: "Serial"
   triggers:
   -
      type: "GitHub"
      github:
         secret: "<Secrete file name>"
   - type: "Generic"
   generic:
      secret: "secret101"
   -
   type: "ImageChange"
   source:
      type: "<Source of code>"
      git:
   uri: "https://github.com/openshift/openshift-hello-world"
   dockerfile: "FROM openshift/openshift-22-centos7\nUSER example"
   strategy:
      type: "Source"
      
sourceStrategy:
   from:
      kind: "ImageStreamTag"
      name: "openshift-20-centos7:latest"
   output:
      to:
         kind: "ImageStreamTag"
         name: "origin-openshift-sample:latest"
   postCommit:
      script: "bundle exec rake test"

Trong OpenShift, có bốn loại chiến lược xây dựng.

  • Chiến lược từ nguồn thành hình ảnh
  • Chiến lược Docker
  • Chiến lược tùy chỉnh
  • Chiến lược đường ống

Chiến lược từ nguồn thành hình ảnh

Cho phép tạo hình ảnh vùng chứa bắt đầu từ mã nguồn. Trong luồng này, mã thực được tải xuống đầu tiên trong vùng chứa và sau đó được biên dịch bên trong nó. Mã đã biên dịch được triển khai bên trong cùng một vùng chứa và hình ảnh được tạo từ mã đó.

strategy:
   type: "Source"
   sourceStrategy:
      from:
         kind: "ImageStreamTag"
         name: "builder-image:latest"
      forcePull: true

Có nhiều chính sách chiến lược.

  • Forcepull
  • Công trình tăng dần
  • Công trình bên ngoài

Chiến lược Docker

Trong luồng này, OpenShift sử dụng Dockerfile để xây dựng hình ảnh và sau đó tải các hình ảnh đã tạo lên sổ đăng ký Docker.

strategy:
   type: Docker
   dockerStrategy:
      from:
         kind: "ImageStreamTag"
         name: "ubuntu:latest"

Tùy chọn tệp Docker có thể được sử dụng ở nhiều vị trí bắt đầu từ đường dẫn tệp, không có bộ nhớ cache và lực kéo.

  • Từ bức ảnh
  • Đường dẫn tệp Docker
  • Không có bộ nhớ cache
  • Lực kéo

Chiến lược tùy chỉnh

Đây là một trong những loại chiến lược xây dựng khác nhau, trong đó không có sự ép buộc nào đến mức đầu ra của việc xây dựng sẽ là một hình ảnh. Nó có thể được so sánh với một công việc phong cách tự do của Jenkins. Với điều này, chúng ta có thể tạo Jar, rpm và các gói khác.

strategy:
   type: "Custom"
   customStrategy:
      from:
         kind: "DockerImage"
         name: "openshift/sti-image-builder"

Nó bao gồm nhiều chiến lược xây dựng.

  • Mở ổ cắm Docker
  • Secrets
  • Lực kéo

Chiến lược đường ống

Chiến lược đường ống được sử dụng để tạo đường ống xây dựng tùy chỉnh. Điều này về cơ bản được sử dụng để thực hiện quy trình làm việc trong đường ống. Luồng xây dựng này sử dụng luồng xây dựng tùy chỉnh sử dụng ngôn ngữ Groovy DSL. OpenShift sẽ tạo một công việc đường ống trong Jenkins và thực thi nó. Luồng đường ống này cũng có thể được sử dụng trong Jenkins. Trong chiến lược này, chúng tôi sử dụng Jenkinsfile và thêm nó vào định nghĩa buildconfig.

Strategy:
   type: "JenkinsPipeline"
   jenkinsPipelineStrategy:
   jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}"

Using build pipeline

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "test-pipeline"
spec:
   source:
      type: "Git"
      git:
         uri: "https://github.com/openshift/openshift-hello-world"
   strategy:
      type: "JenkinsPipeline"
      jenkinsPipelineStrategy:
         jenkinsfilePath: <file path repository>

OpenShift CLI được sử dụng để quản lý các ứng dụng OpenShift từ dòng lệnh. OpenShift CLI có khả năng quản lý vòng đời của ứng dụng từ đầu đến cuối. Nói chung, chúng tôi sẽ sử dụng OC, một ứng dụng khách OpenShift để giao tiếp với OpenShift.

Thiết lập OpenShift CLI

Để thiết lập máy khách OC trên một hệ điều hành khác, chúng ta cần thực hiện các bước theo trình tự khác nhau.

OC Client dành cho Windows

Step 1 - Tải về cli oc từ liên kết sau https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Step 2 - Giải nén gói trên đường dẫn đích trên máy.

Step 3 - Chỉnh sửa biến môi trường đường dẫn của hệ thống.

C:\Users\xxxxxxxx\xxxxxxxx>echo %PATH%

C:\oraclexe\app\oracle\product\10.2.0\server\bin;C:\Program Files 
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Program Files 
(x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\
v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files 
(x86)\ATI Technologies\ATI.ACE\C

ore-Static;C:\Program Files\Intel\Intel(R) Management Engine 
Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine 
Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;

Step 4 - Xác thực thiết lập OC trên Windows.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc version
oc v3.6.0-alpha.2+3c221d5
kubernetes v1.6.1+5115d708d7
features: Basic-Auth

OC Client dành cho Mac OS X

Chúng ta có thể tải xuống tệp nhị phân thiết lập Mac OS cho cùng một vị trí như cho Windows và sau đó giải nén nó tại một vị trí và đặt đường dẫn có thể thực thi trong biến môi trường PATH.

Alternatively

Chúng ta có thể sử dụng Home brew và thiết lập nó bằng lệnh sau.

$ brew install openshift-cli

OC Client dành cho Linux

Trong cùng một trang, chúng tôi có tệp tar để cài đặt Linux có thể được sử dụng để cài đặt. Sau đó, một biến đường dẫn có thể được đặt trỏ đến vị trí thực thi cụ thể đó.

https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Giải nén tệp tar bằng lệnh sau.

$ tar –xf < path to the OC setup tar file >

Chạy lệnh sau để kiểm tra xác thực.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc login
Server [https://localhost:8443]:

Tệp cấu hình CLI

Tệp cấu hình OC CLI được sử dụng để quản lý nhiều kết nối máy chủ OpenShift và cơ chế xác thực. Tệp cấu hình này cũng được sử dụng để lưu trữ và quản lý nhiều cấu hình và để chuyển đổi giữa chúng. Tệp cấu hình bình thường trông giống như sau.

$ oc config view
apiVersion: v1
clusters:
   - cluster:
      server: https://vklnld908.int.example.com
   name: openshift
   
contexts:
- context:
   cluster: openshift
   namespace: testproject
   user: alice
   name: alice
current-context: alice
kind: Config
preferences: {}
users:
- name: vipin
   user:
      token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Thiết lập ứng dụng khách CLI

Để thiết lập thông tin người dùng

$ oc config set-credentials <user_nickname>
[--client-certificate = <path/to/certfile>] [--client-key=<path/to/keyfile>]
[--token = <bearer_token>] [--username = <basic_user>] [--password = <basic_password>]

Đối với cụm thiết lập

$ oc config set-cluster <cluster_nickname> [--server = <master_ip_or_fqdn>]
[--certificate-authority = <path/to/certificate/authority>]
[--api-version = <apiversion>] [--insecure-skip-tls-verify = true]

Thí dụ

$ oc config set-credentials vipin --token = ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Để thiết lập ngữ cảnh

$ oc config set-context <context_nickname> [--cluster = <cluster_nickname>]
[--user = <user_nickname>] [--namespace = <namespace>]

Hồ sơ CLI

Trong một tệp cấu hình CLI duy nhất, chúng ta có thể có nhiều cấu hình trong đó mỗi cấu hình có một cấu hình máy chủ OpenShift khác nhau, sau này có thể được sử dụng để chuyển đổi giữa các cấu hình CLI khác nhau.

apiVersion: v1
clusters: --→ 1
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld908.int.example.com:8443
   name: vklnld908.int.example.com:8443
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld1446.int.example.com:8443
   name: vklnld1446.int.example.com:8443
contexts: ---→ 2
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: openshift-project
   user: vipin/vklnld908.int.example.com:8443
   name: openshift-project/vklnld908.int.example.com:8443/vipin
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: testing-project
   user: alim/vklnld908.int.example.com:8443
   name: testproject-project/openshift1/alim
current-context: testing-project/vklnld908.int.example.com:8443/vipin - 3
kind: Config
preferences: {}

users:
- name: vipin/vklnld908.int.example.com:8443
user: ---→ 4
   token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Trong cấu hình trên, chúng ta có thể thấy nó được chia thành bốn phần chính bắt đầu từ cụm xác định hai phiên bản của máy chủ OpenShift. Phần ngữ cảnh thứ hai xác định hai ngữ cảnh có tên là vipin và alim. Ngữ cảnh hiện tại xác định ngữ cảnh nào hiện đang được sử dụng. Nó có thể được thay đổi thành ngữ cảnh hoặc hồ sơ khác, nếu chúng ta thay đổi định nghĩa ở đây. Cuối cùng, định nghĩa người dùng và mã thông báo xác thực của nó được xác định mà trong trường hợp của chúng tôi là vipin.

Nếu chúng ta muốn kiểm tra cấu hình hiện tại đang được sử dụng, nó có thể được thực hiện bằng cách sử dụng -

$ oc status oc status In project testing Project (testing-project) $ oc project
Using project "testing-project" from context named "testing-
project/vklnld908.int.example.com:8443/vipin" on server "https://vklnld908.int.example.com:8443".

Nếu chúng ta muốn chuyển sang CLI khác, nó có thể được thực hiện từ dòng lệnh bằng cách sử dụng lệnh sau.

$ oc project openshift-project
Now using project "Openshift-project" on server "
https://vklnld908.int.example.com:8443".

Sử dụng lệnh trên, chúng ta có thể chuyển đổi giữa các cấu hình. Tại bất kỳ thời điểm nào, nếu chúng ta muốn xem cấu hình, chúng ta có thể sử dụng lệnh $ oc config view view.

OpenShift CLI có khả năng thực hiện tất cả các cấu hình, quản lý, bổ sung và triển khai ứng dụng cơ bản và nâng cao.

Chúng tôi có thể thực hiện các loại hoạt động khác nhau bằng cách sử dụng các lệnh OC. Ứng dụng khách này giúp bạn phát triển, xây dựng, triển khai và chạy các ứng dụng của mình trên bất kỳ nền tảng tương thích OpenShift hoặc Kubernetes nào. Nó cũng bao gồm các lệnh quản trị để quản lý một cụm trong lệnh con 'adm'.

Các lệnh cơ bản

Bảng sau liệt kê các lệnh OC cơ bản.

Sr.No. Lệnh & Mô tả
1

Types

Giới thiệu về các khái niệm và loại
2

Login

Đăng nhập vào máy chủ
3

new-project

Yêu cầu một dự án mới
4

new-app

Tạo một ứng dụng mới
5

Status

Hiển thị tổng quan về dự án hiện tại
6

Project

Chuyển sang dự án khác
7

Projects

Hiển thị các dự án hiện có
số 8

Explain

Tài liệu về nguồn
9

Cluster

Bắt đầu và dừng cụm OpenShift

Đăng nhập

Đăng nhập vào máy chủ của bạn và lưu thông tin đăng nhập để sử dụng tiếp theo. Người dùng lần đầu tiên của máy khách nên chạy lệnh này để kết nối với máy chủ, thiết lập phiên được xác thực và lưu kết nối vào tệp cấu hình. Cấu hình mặc định sẽ được lưu vào thư mục chính của bạn trong ".kube / config".

Thông tin cần thiết để đăng nhập - như tên người dùng và mật khẩu, mã thông báo phiên hoặc chi tiết máy chủ có thể được cung cấp thông qua cờ. Nếu không được cung cấp, lệnh sẽ nhắc người dùng nhập khi cần.

Usage

oc login [URL] [options]

Example

# Log in interactively
oc login

# Log in to the given server with the given certificate authority file
oc login localhost:8443 --certificate-authority = /path/to/cert.crt

# Log in to the given server with the given credentials (will not prompt interactively)
oc login localhost:8443 --username = myuser --password=mypass

Tùy chọn -

-p, --password = " - Mật khẩu, sẽ nhắc nếu không được cung cấp

-u, --username = " - Tên người dùng, sẽ nhắc nếu không được cung cấp

--certificate-authority = "- Đường dẫn đến một chứng chỉ. nộp cho cơ quan cấp chứng chỉ

--insecure-skip-tls-verify = false- Nếu đúng, chứng chỉ của máy chủ sẽ không được kiểm tra tính hợp lệ. Điều này sẽ làm cho các kết nối HTTPS của bạn không an toàn

--token = " - Mã thông báo mang để xác thực máy chủ API

Để biết chi tiết đầy đủ về bất kỳ lệnh nào, hãy sử dụng oc <Command Name> --help chỉ huy.

Xây dựng và triển khai lệnh

Bảng sau liệt kê các lệnh xây dựng và triển khai.

Sr.No. Lệnh & Mô tả
1

Rollout

Quản lý triển khai Kubernetes hoặc triển khai OpenShift
2

Deploy

Xem, bắt đầu, hủy hoặc thử lại một triển khai
3

Rollback

Hoàn nguyên một phần của ứng dụng về trạng thái trước đó
4

new-build

Tạo cấu hình bản dựng mới
5

start-build

Bắt đầu một bản dựng mới
6

cancel-build

Hủy các bản dựng mới đang chạy, đang chờ xử lý hoặc
7

import-image

Nhập hình ảnh từ sổ đăng ký Docker
số 8

Tag

Gắn thẻ các hình ảnh hiện có vào luồng hình ảnh

Lệnh quản lý ứng dụng

Bảng sau liệt kê các lệnh quản lý ứng dụng.

Sr.No. Lệnh & Mô tả
1

Get

Hiển thị một hoặc nhiều tài nguyên
2

Describe

Hiển thị chi tiết của một tài nguyên cụ thể hoặc một nhóm tài nguyên
3

Edit

Chỉnh sửa tài nguyên trên máy chủ
4

Set

Các lệnh giúp thiết lập các tính năng cụ thể trên các đối tượng
5

Label

Cập nhật nhãn trên tài nguyên
6

Annotate

Cập nhật các chú thích trên một tài nguyên
7

Expose

Hiển thị một ứng dụng sao chép dưới dạng một dịch vụ hoặc tuyến đường
số 8

Delete

Xóa một hoặc nhiều tài nguyên
9

Scale

Thay đổi số lượng nhóm trong một lần triển khai
10

Autoscale

Tự động phân tỷ lệ cấu hình triển khai, triển khai, nhân rộng, Bộ điều khiển hoặc tập hợp bản sao
11

Secrets

Quản lý bí mật
12

Serviceaccounts

Quản lý tài khoản dịch vụ trong dự án của bạn

Các lệnh khắc phục sự cố và gỡ lỗi

Bảng sau liệt kê các lệnh gỡ rối và gỡ lỗi.

Sr.No. Lệnh & Mô tả
1

logs

In nhật ký cho một tài nguyên
2

Rsh

Bắt đầu một phiên trình bao trong một nhóm
3

Rsync

Sao chép tệp giữa hệ thống tệp cục bộ và nhóm
4

port-forward

Chuyển tiếp một hoặc nhiều cổng cục bộ tới một nhóm
5

Debug

Khởi chạy phiên bản mới của nhóm để gỡ lỗi
6

Exec

Thực thi một lệnh trong vùng chứa
7

Procy

Chạy proxy tới máy chủ Kubernetes API
9

Attach

Đính kèm vào một vùng chứa đang chạy
10

Run

Chạy một hình ảnh cụ thể trên cụm
11

Cp

Sao chép tệp và thư mục đến và từ vùng chứa

Lệnh nâng cao

Bảng sau liệt kê các lệnh nâng cao.

Sr.No. Lệnh & Mô tả
1

adm

Các công cụ để quản lý một cụm
2

create

Tạo tài nguyên theo tên tệp hoặc stdin
3

replace

Thay thế tài nguyên bằng tên tệp hoặc stdin
4

apply

Áp dụng cấu hình cho tài nguyên theo tên tệp hoặc stdin
5

patch

Cập nhật (các) trường của tài nguyên bằng cách sử dụng bản vá hợp nhất chiến lược
6

process

Xử lý một mẫu thành danh sách tài nguyên
7

export

Xuất tài nguyên để chúng có thể được sử dụng ở nơi khác
số 8

extract

Trích xuất bí mật hoặc cấu hình bản đồ vào đĩa
9

idle

Tài nguyên có thể mở rộng không hoạt động
10

observe

Quan sát các thay đổi đối với tài nguyên và phản ứng với chúng (thử nghiệm)
11

policy

Quản lý chính sách ủy quyền
12

auth

Kiểm tra ủy quyền
13

convert

Chuyển đổi tệp cấu hình giữa các phiên bản API khác nhau
14

import

Các lệnh nhập ứng dụng

Đặt lệnh

Bảng sau liệt kê các lệnh cài đặt.

Sr.No. Lệnh & Mô tả
1

Logout

Kết thúc phiên máy chủ hiện tại
2

Config

Thay đổi các tệp cấu hình cho máy khách
3

Whoami

Trả lại thông tin về phiên hiện tại
4

Completion

Mã hoàn thành trình bao đầu ra cho trình bao được chỉ định (bash hoặc zsh)

OpenShift sử dụng hai phương pháp cài đặt để thiết lập cụm OpenShift.

  • Phương pháp cài đặt nhanh chóng
  • Phương pháp cấu hình nâng cao

Thiết lập cụm

Phương pháp cài đặt nhanh

Phương pháp này được sử dụng để chạy cấu hình thiết lập cụm nhanh chóng. Để sử dụng phương pháp này, trước tiên chúng ta cần cài đặt trình cài đặt. Điều này có thể được thực hiện bằng cách chạy lệnh sau.

Interactive method

$ atomic-openshift-installer install

Điều này hữu ích khi một người muốn chạy một thiết lập tương tác.

Unattended installation method

Phương pháp này được sử dụng khi một người muốn thiết lập một phương thức cài đặt không cần giám sát, trong đó người dùng có thể xác định tệp yaml cấu hình và đặt nó dưới ~/.config/openshift/với tên của installer.cfg.yml. Sau đó, có thể chạy lệnh sau để cài đặt–u tag.

$ atomic-openshift-installer –u install

Theo mặc định, nó sử dụng tệp cấu hình nằm dưới ~/.config/openshift/. Mặt khác, Ansible được sử dụng như một bản sao lưu cài đặt.

version: v2
variant: openshift-enterprise
variant_version: 3.1
ansible_log_path: /tmp/ansible.log

deployment:
   ansible_ssh_user: root
   hosts:
   - ip: 172.10.10.1
   hostname: vklnld908.int.example.com
   public_ip: 24.222.0.1
   public_hostname: master.example.com
   roles:
      - master
      - node
   containerized: true
   connect_to: 24.222.0.1
   
   - ip: 172.10.10.2
   hostname: vklnld1446.int.example.com
   public_ip: 24.222.0.2
   public_hostname: node1.example.com
   roles:
      - node
   connect_to: 10.0.0.2
   
   - ip: 172.10.10.3
   hostname: vklnld1447.int.example.com
   public_ip: 10..22.2.3
   public_hostname: node2.example.com
   roles:
      - node
   connect_to: 10.0.0.3

roles:
   master:
      <variable_name1>: "<value1>"
      <variable_name2>: "<value2>"
   node:
      <variable_name1>: "<value1>"

Ở đây, chúng ta có biến theo vai trò cụ thể, có thể được xác định nếu người ta muốn thiết lập một số biến cụ thể.

Sau khi hoàn tất, chúng ta có thể xác minh cài đặt bằng lệnh sau.

$ oc get nodes
NAME                    STATUS    AGE
master.example.com      Ready     10d
node1.example.com       Ready     10d
node2.example.com       Ready     10d

Cài đặt nâng cao

Cài đặt nâng cao hoàn toàn dựa trên cấu hình Ansible, trong đó cấu hình máy chủ hoàn chỉnh và định nghĩa các biến liên quan đến cấu hình chính và nút có sẵn. Điều này chứa tất cả các chi tiết liên quan đến cấu hình.

Khi chúng tôi đã thiết lập xong và playbook đã sẵn sàng, chúng tôi chỉ cần chạy lệnh sau để thiết lập cụm.

$ ansible-playbook -i inventry/hosts ~/openshift-ansible/playbooks/byo/config.yml

Thêm máy chủ vào một cụm

Chúng ta có thể thêm một máy chủ vào cụm bằng cách sử dụng -

  • Công cụ cài đặt nhanh
  • Phương pháp cấu hình nâng cao

Quick installation toolhoạt động ở cả chế độ tương tác và không tương tác. Sử dụng lệnh sau.

$ atomic-openshift-installer -u -c </path/to/file> scaleup

Định dạng chia tỷ lệ giao diện tệp cấu hình ứng dụng có thể được sử dụng để thêm cả nút chính cũng như nút.

Phương pháp cấu hình nâng cao

Trong phương pháp này, chúng tôi cập nhật tệp máy chủ của Ansible và sau đó thêm một nút hoặc chi tiết máy chủ mới trong tệp này. Tệp cấu hình trông giống như sau.

[OSEv3:children]
masters
nodes
new_nodes
new_master

Trong cùng một tệp máy chủ Ansible, hãy thêm các chi tiết biến liên quan đến nút mới như được hiển thị bên dưới.

[new_nodes]
vklnld1448.int.example.com openshift_node_labels = "{'region': 'primary', 'zone': 'east'}"

Cuối cùng, sử dụng tệp máy chủ đã cập nhật, chạy cấu hình mới và gọi tệp cấu hình để hoàn tất thiết lập bằng lệnh sau.

$ ansible-playbook -i /inventory/hosts /usr/share/ansible/openshift-ansible/playbooks/test/openshift-node/scaleup.yml

Quản lý Nhật ký Cụm

Nhật ký cụm OpenShift không là gì ngoài các nhật ký được tạo từ máy chủ và máy nút của cụm. Chúng có thể quản lý bất kỳ loại nhật ký nào, bắt đầu từ nhật ký máy chủ, nhật ký chính, nhật ký vùng chứa, nhật ký nhóm, v.v. Có nhiều công nghệ và ứng dụng hiện có để quản lý nhật ký vùng chứa.

Một số công cụ như được liệt kê có thể được triển khai để quản lý nhật ký.

  • Fluentd
  • ELK
  • Kabna
  • Nagios
  • Splunk

ELK stack- Ngăn xếp này hữu ích khi cố gắng thu thập nhật ký từ tất cả các nút và trình bày chúng ở định dạng có hệ thống. Ngăn xếp ELK chủ yếu được chia thành ba loại chính.

ElasticSearch - Chịu trách nhiệm chính trong việc thu thập thông tin từ tất cả các thùng chứa và đưa nó vào vị trí trung tâm.

Fluentd - Được sử dụng để cung cấp các bản ghi đã thu thập cho động cơ chứa co giãn.

Kibana - Giao diện đồ họa được sử dụng để trình bày dữ liệu thu thập được dưới dạng thông tin hữu ích trong giao diện đồ họa.

Một điểm quan trọng cần lưu ý là, khi hệ thống này được triển khai trên cụm, nó bắt đầu thu thập nhật ký từ tất cả các nút.

Chẩn đoán nhật ký

OpenShift có sẵn oc adm dignosticslệnh với OC có thể được sử dụng để phân tích nhiều tình huống lỗi. Công cụ này có thể được sử dụng từ chính với tư cách là quản trị viên cụm. Tiện ích này rất hữu ích trong việc khắc phục sự cố và xác định các vấn đề đã biết. Điều này chạy trên máy khách chính và các nút.

Nếu chạy mà không có bất kỳ agruments hoặc cờ nào, nó sẽ tìm kiếm các tệp cấu hình của máy khách, máy chủ và nút machnies và sử dụng chúng để chẩn đoán. Người ta có thể chạy chẩn đoán riêng lẻ bằng cách chuyển các đối số sau:

  • AggregatedLogging
  • AnalyzeLogs
  • ClusterRegistry
  • ClusterRoleBindings
  • ClusterRoles
  • ClusterRouter
  • ConfigContexts
  • DiagnosticPod
  • MasterConfigCheck
  • MasterNode
  • MetricsApiProxy
  • NetworkCheck
  • NodeConfigCheck
  • NodeDefinitions
  • ServiceExternalIPs
  • UnitStatus

Người ta có thể đơn giản chạy chúng bằng lệnh sau.

$ oc adm diagnostics <DiagnosticName>

Nâng cấp một cụm

Nâng cấp cụm liên quan đến việc nâng cấp nhiều thứ bên trong cụm và định vị địa lý cho cụm được cập nhật với các thành phần và phần bổ sung mới. Điều này liên quan đến -

  • Nâng cấp các thành phần chính
  • Nâng cấp các thành phần nút
  • Nâng cấp các chính sách
  • Nâng cấp các tuyến đường
  • Nâng cấp luồng hình ảnh

Để thực hiện tất cả các nâng cấp này, trước tiên chúng tôi cần phải có các trình cài đặt nhanh hoặc các utils tại chỗ. Vì vậy, chúng tôi cần cập nhật các tiện ích sau:

  • atomic-openshift-utils
  • atomic-openshift-excluder
  • atomic-openshift-docker-excluder
  • gói etcd

Trước khi bắt đầu nâng cấp, chúng ta cần sao lưu etcd trên máy chủ, có thể thực hiện bằng các lệnh sau.

$ ETCD_DATA_DIR = /var/lib/origin/openshift.local.etcd
$ etcdctl backup \ --data-dir $ETCD_DATA_DIR \
   --backup-dir $ETCD_DATA_DIR.bak.<date>

Nâng cấp các thành phần chính

Trong OpenShift master, chúng tôi bắt đầu nâng cấp bằng cách cập nhật tệp etcd và sau đó chuyển sang Docker. Cuối cùng, chúng tôi chạy trình thực thi tự động để đưa cụm vào vị trí cần thiết. Tuy nhiên, trước khi bắt đầu nâng cấp, trước tiên chúng ta cần kích hoạt các gói openshift nguyên tử trên mỗi bản chính. Điều này có thể được thực hiện bằng cách sử dụng các lệnh sau.

Step 1 - Loại bỏ các gói mở nguyên tử

$ atomic-openshift-excluder unexclude

Step 2 - Nâng cấp etcd trên tất cả các bậc thầy.

$ yum update etcd

Step 3 - Khởi động lại dịch vụ của etcd và kiểm tra xem nó đã bắt đầu thành công chưa.

$ systemctl restart etcd
$ journalctl -r -u etcd

Step 4 - Nâng cấp gói Docker.

$ yum update docker

Step 5 - Khởi động lại dịch vụ Docker và kiểm tra xem nó đã được lên đúng chưa.

$ systemctl restart docker $ journalctl -r -u docker

Step 6 - Sau khi hoàn tất, khởi động lại hệ thống bằng các lệnh sau.

$ systemctl reboot $ journalctl -r -u docker

Step 7 - Cuối cùng, chạy trình thực thi nguyên tử để đưa các gói trở lại danh sách loại trừ yum.

$ atomic-openshift-excluder exclude

Không có sự bắt buộc nào như vậy đối với việc nâng cấp chính sách, nó chỉ cần được nâng cấp nếu được khuyến nghị, có thể kiểm tra bằng lệnh sau.

$ oadm policy reconcile-cluster-roles

Trong hầu hết các trường hợp, chúng tôi không cần cập nhật định nghĩa chính sách.

Nâng cấp các thành phần nút

Sau khi cập nhật chính hoàn tất, chúng tôi có thể bắt đầu nâng cấp các nút. Một điều cần lưu ý là thời gian nâng cấp phải ngắn để tránh bất kỳ loại vấn đề nào trong cụm.

Step 1 - Xóa tất cả các gói OpenShift nguyên tử khỏi tất cả các nút mà bạn muốn thực hiện nâng cấp.

$ atomic-openshift-excluder unexclude

Step 2 - Tiếp theo, vô hiệu hóa lập lịch nút trước khi nâng cấp.

$ oadm manage-node <node name> --schedulable = false

Step 3 - Sao chép tất cả các nút từ máy chủ hiện tại sang máy chủ khác.

$ oadm drain <node name> --force --delete-local-data --ignore-daemonsets

Step 4 - Nâng cấp thiết lập Docker trên máy chủ.

$ yum update docker

Step 5 - Khởi động lại dịch vụ Docker và sau đó khởi động nút dịch vụ Docker.

$systemctl restart docker $ systemctl restart atomic-openshift-node

Step 6 - Kiểm tra xem cả hai đã khởi động đúng chưa.

$ journalctl -r -u atomic-openshift-node

Step 7 - Sau khi nâng cấp xong, khởi động lại máy nút.

$ systemctl reboot
$ journalctl -r -u docker

Step 8 - Bật lại lập lịch trên các nút.

$ oadm manage-node <node> --schedulable.

Step 9 - Chạy trình thực thi nguyên tử-openshift để lấy lại gói OpenShift trên nút.

$ atomic-openshift-excluder exclude

Step 10 - Cuối cùng, kiểm tra xem tất cả các nút có sẵn hay không.

$ oc get nodes

NAME                 STATUS   AGE
master.example.com   Ready    12d
node1.example.com    Ready    12d
node2.example.com    Ready    12d

Tự động thay đổi quy mô là một tính năng trong OpenShift nơi các ứng dụng được triển khai có thể mở rộng quy mô và chìm khi có yêu cầu theo thông số kỹ thuật nhất định. Trong ứng dụng OpenShift, tính năng autoscaling còn được gọi là pod autoscaling. Có haitypes of application scaling như sau.

Chia tỷ lệ dọc

Chia tỷ lệ dọc là tất cả về việc tăng thêm ngày càng nhiều sức mạnh cho một máy duy nhất, nghĩa là thêm nhiều CPU và đĩa cứng. Đây là một phương pháp cũ của OpenShift hiện không được các bản phát hành OpenShift hỗ trợ.

Chia tỷ lệ ngang

Kiểu chia tỷ lệ này rất hữu ích khi cần xử lý nhiều yêu cầu hơn bằng cách tăng số lượng máy.

Trong OpenShift, có two methods to enable the scaling feature.

  • Sử dụng tệp cấu hình triển khai
  • Trong khi chạy hình ảnh

Sử dụng tệp cấu hình triển khai

Trong phương pháp này, tính năng mở rộng quy mô được kích hoạt thông qua tệp yaml cấu hình người triển khai. Đối với điều này, lệnh OC tự động tỷ lệ được sử dụng với số lượng bản sao tối thiểu và tối đa, lệnh này cần chạy tại bất kỳ thời điểm nhất định nào trong cụm. Chúng ta cần một định nghĩa đối tượng để tạo autoscaler. Sau đây là một ví dụ về tệp định nghĩa pod autoscaler.

apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
   name: database
spec:
   scaleRef:
      kind: DeploymentConfig
      name: database
      apiVersion: v1
      subresource: scale
   minReplicas: 1
   maxReplicas: 10
   cpuUtilization:
      targetPercentage: 80

Khi chúng tôi đã có tệp tại chỗ, chúng tôi cần lưu nó với định dạng yaml và chạy lệnh sau để triển khai.

$ oc create –f <file name>.yaml

Trong khi chạy hình ảnh

Người ta cũng có thể tự động xếp tỷ lệ mà không cần tệp yaml, bằng cách sử dụng oc autoscale lệnh trong dòng lệnh oc.

$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75
deploymentconfig "database" autoscaled

Lệnh này cũng sẽ tạo ra một loại tệp tương tự mà sau này có thể được sử dụng để tham khảo.

Các chiến lược triển khai trong OpenShift

Chiến lược triển khai trong OpenShift xác định luồng triển khai với các phương pháp có sẵn khác nhau. Trong OpenShift, sau đây làimportant types of deployment strategies.

  • Chiến lược cuộn
  • Tạo lại chiến lược
  • Chiến lược tùy chỉnh

Sau đây là một ví dụ về tệp cấu hình triển khai, được sử dụng chủ yếu để triển khai trên các nút OpenShift.

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
   name: "database"
spec:
   template:
      metadata:
         labels:
            name: "Database1"
spec:
   containers:
      - name: "vipinopenshifttest"
         image: "openshift/mongoDB"
         ports:
            - containerPort: 8080
               protocol: "TCP"
replicas: 5
selector:
   name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
   imageChangeParams:
      automatic: true
      containerNames:
         - "vipinopenshifttest"
      from:
         kind: "ImageStreamTag"
         name: "mongoDB:latest"
   strategy:
      type: "Rolling"

Trong tệp Deploymentconfig ở trên, chúng ta có chiến lược là Rolling.

Chúng ta có thể sử dụng lệnh OC sau để triển khai.

$ oc deploy <deployment_config> --latest

Chiến lược cuộn

Chiến lược cuộn được sử dụng để cập nhật hoặc triển khai luân phiên. Quá trình này cũng hỗ trợ các móc vòng đời, được sử dụng để đưa mã vào bất kỳ quá trình triển khai nào.

strategy:
   type: Rolling
   rollingParams:
      timeoutSeconds: <time in seconds>
      maxSurge: "<definition in %>"
      maxUnavailable: "<Defintion in %>"
      pre: {}
      post: {}

Tạo lại chiến lược

Chiến lược triển khai này có một số tính năng cơ bản của chiến lược triển khai cuốn chiếu và nó cũng hỗ trợ móc vòng đời.

strategy:
   type: Recreate
   recreateParams:
      pre: {}
      mid: {}
      post: {}

Chiến lược tùy chỉnh

Điều này rất hữu ích khi một người muốn cung cấp quy trình hoặc luồng triển khai của riêng mình. Tất cả các tùy chỉnh có thể được thực hiện theo yêu cầu.

strategy:
   type: Custom
   customParams:
      image: organization/mongoDB
      command: [ "ls -l", "$HOME" ]
      environment:
         - name: VipinOpenshiftteat
         value: Dev1

Trong chương này, chúng tôi sẽ đề cập đến các chủ đề như cách quản lý một nút, cấu hình tài khoản dịch vụ, v.v.

Cấu hình chính và nút

Trong OpenShift, chúng ta cần sử dụng lệnh start cùng với OC để khởi động một máy chủ mới. Trong khi khởi chạy một cái chính mới, chúng ta cần sử dụng cái chính cùng với lệnh bắt đầu, trong khi khi khởi động nút mới, chúng ta cần sử dụng nút cùng với lệnh bắt đầu. Để làm được điều này, chúng ta cần tạo các tệp cấu hình cho cái chính cũng như cho các nút. Chúng ta có thể tạo một tệp cấu hình cơ bản cho nút chính và nút bằng cách sử dụng lệnh sau.

Đối với tệp cấu hình chính

$ openshift start master --write-config = /openshift.local.config/master

Đối với tệp cấu hình nút

$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>

Khi chúng tôi chạy các lệnh sau, chúng tôi sẽ nhận được các tệp cấu hình cơ sở có thể được sử dụng làm điểm bắt đầu cho cấu hình. Sau đó, chúng ta có thể có cùng một tệp để khởi động các máy chủ mới.

apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
   logoutURL: ""
   masterPublicURL: https://172.10.12.1:7449
   publicURL: https://172.10.2.2:7449/console/
      servingInfo:
         bindAddress: 0.0.0.0:7449
         certFile: master.server.crt
         clientCA: ""
keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
   bindAddress: 0.0.0.0:53
etcdClientInfo:
   ca: ca.crt
   certFile: master.etcd-client.crt
   keyFile: master.etcd-client.key
   urls:
   - https://10.0.2.15:4001
etcdConfig:
   address: 10.0.2.15:4001
   peerAddress: 10.0.2.15:7001
   peerServingInfo:
      bindAddress: 0.0.0.0:7001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   servingInfo:
      bindAddress: 0.0.0.0:4001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
   kubernetesStoragePrefix: kubernetes.io
   kubernetesStorageVersion: v1
   openShiftStoragePrefix: openshift.io
   openShiftStorageVersion: v1
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: MasterConfig
kubeletClientInfo:
   ca: ca.crt
   certFile: master.kubelet-client.crt
   keyFile: master.kubelet-client.key
   port: 10250
kubernetesMasterConfig:
   apiLevels:
   - v1beta3
   - v1
   apiServerArguments: null
   controllerArguments: null
   masterCount: 1
   masterIP: 10.0.2.15
   podEvictionTimeout: 5m
   schedulerConfigFile: ""
   servicesNodePortRange: 30000-32767
   servicesSubnet: 172.30.0.0/16
   staticNodeNames: []
masterClients:
   externalKubernetesKubeConfig: ""
   openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
   clusterNetworkCIDR: 10.1.0.0/16
   hostSubnetLength: 8
   networkPluginName: ""
   serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
   assetPublicURL: https://172.10.2.2:7449/console/
   grantConfig:
      method: auto
   identityProviders:
   - challenge: true
   login: true
   name: anypassword
   provider:
      apiVersion: v1
      kind: AllowAllPasswordIdentityProvider
   masterPublicURL: https://172.10.2.2:7449/
   masterURL: https://172.10.2.2:7449/
   sessionConfig:
      sessionMaxAgeSeconds: 300
      sessionName: ssn
      sessionSecretsFile: ""
   tokenConfig:
      accessTokenMaxAgeSeconds: 86400
      authorizeTokenMaxAgeSeconds: 300
policyConfig:
   bootstrapPolicyFile: policy.json
   openshiftInfrastructureNamespace: openshift-infra
   openshiftSharedResourcesNamespace: openshift
projectConfig:
   defaultNodeSelector: ""
   projectRequestMessage: ""
   projectRequestTemplate: ""
   securityAllocator:
      mcsAllocatorRange: s0:/2
      mcsLabelsPerProject: 5
      uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
   subdomain: router.default.svc.cluster.local
serviceAccountConfig:
   managedNames:
   - default
   - builder
   - deployer
   
masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
servingInfo:
   bindAddress: 0.0.0.0:8443
   certFile: master.server.crt
   clientCA: ca.crt
   keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 3600

Tệp cấu hình nút

allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
   execHandlerName: native
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
   mtu: 1450
   networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com

podManifestConfig:
   path: "/path/to/pod-manifest-file"
   fileCheckIntervalSeconds: 30
servingInfo:
   bindAddress: 0.0.0.0:10250
   certFile: server.crt
   clientCA: node-client-ca.crt
   keyFile: server.key
volumeDirectory: /root/openshift.local.volumes

Đây là cách các tệp cấu hình nút trông như thế nào. Khi chúng ta có các tệp cấu hình này, chúng ta có thể chạy lệnh sau để tạo máy chủ chính và máy chủ nút.

$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml

Quản lý các nút

Trong OpenShift, chúng ta có tiện ích dòng lệnh OC, tiện ích này chủ yếu được sử dụng để thực hiện tất cả các hoạt động trong OpenShift. Chúng ta có thể sử dụng các lệnh sau để quản lý các nút.

Để liệt kê một nút

$ oc get nodes
NAME                             LABELS
node1.example.com     kubernetes.io/hostname = vklnld1446.int.example.com
node2.example.com     kubernetes.io/hostname = vklnld1447.int.example.com

Mô tả chi tiết về một nút

$ oc describe node <node name>

Xóa một nút

$ oc delete node <node name>

Liệt kê các nhóm trên một nút

$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

Đánh giá nhóm trên một nút

$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]

Xác thực cấu hình

Trong OpenShift master, có một máy chủ OAuth tích hợp, có thể được sử dụng để quản lý xác thực. Tất cả người dùng OpenShift đều nhận được mã thông báo từ máy chủ này, giúp họ giao tiếp với API OpenShift.

Có nhiều loại cấp độ xác thực khác nhau trong OpenShift, có thể được định cấu hình cùng với tệp cấu hình chính.

  • Chấp nhận tất cả
  • Phủ nhận tất cả
  • HTPasswd
  • LDAP
  • Xác thực cơ bản
  • Tiêu đề yêu cầu

Trong khi xác định cấu hình chính, chúng ta có thể xác định chính sách nhận dạng nơi chúng ta có thể xác định loại chính sách mà chúng ta muốn sử dụng.

Chấp nhận tất cả

Chấp nhận tất cả

oauthConfig:
   ...
   identityProviders:
   - name: Allow_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Phủ nhận tất cả

Điều này sẽ từ chối quyền truy cập vào tất cả tên người dùng và mật khẩu.

oauthConfig:
   ...
   identityProviders:
   - name: deny_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: DenyAllPasswordIdentityProvider

HTPasswd

HTPasswd được sử dụng để xác thực tên người dùng và mật khẩu so với mật khẩu tệp được mã hóa.

Để tạo một tệp được mã hóa, sau đây là lệnh.

$ htpasswd </path/to/users.htpasswd> <user_name>

Sử dụng tệp được mã hóa.

oauthConfig:
   ...
   identityProviders:
   - name: htpasswd_authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider
         file: /path/to/users.htpasswd

Nhà cung cấp danh tính LDAP

Điều này được sử dụng để xác thực LDAP trong đó máy chủ LDAP đóng một vai trò quan trọng trong xác thực.

oauthConfig:
   ...
   identityProviders:
   - name: "ldap_authontication"
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: LDAPPasswordIdentityProvider
         attributes:
            id:
            - dn
            email:
            - mail
            name:
            - cn
            preferredUsername:
            - uid
         bindDN: ""
         bindPassword: ""
         ca: my-ldap-ca-bundle.crt
         insecure: false
         url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"

Xác thực cơ bản

Điều này được sử dụng khi xác thực tên người dùng và mật khẩu được thực hiện dựa trên xác thực từ máy chủ đến máy chủ. Xác thực được bảo vệ trong URL cơ sở và được trình bày ở định dạng JSON.

oauthConfig:
   ...
   identityProviders:
   - name: my_remote_basic_auth_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: BasicAuthPasswordIdentityProvider
         url: https://www.vklnld908.int.example.com/remote-idp
         ca: /path/to/ca.file
         certFile: /path/to/client.crt
         keyFile: /path/to/client.key

Định cấu hình tài khoản dịch vụ

Tài khoản dịch vụ cung cấp một cách linh hoạt để truy cập API OpenShift, làm lộ tên người dùng và mật khẩu để xác thực.

Kích hoạt tài khoản dịch vụ

Tài khoản dịch vụ sử dụng một cặp khóa công khai và khóa riêng tư để xác thực. Xác thực API được thực hiện bằng cách sử dụng khóa riêng tư và xác thực nó dựa trên khóa công khai.

ServiceAccountConfig:
   ...
   masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
   - ...

Tạo tài khoản dịch vụ

Sử dụng lệnh sau để tạo tài khoản dịch vụ

$ Openshift cli create service account <name of server account>

Làm việc với HTTP Proxy

Trong hầu hết các môi trường sản xuất, truy cập trực tiếp vào Internet bị hạn chế. Chúng không được tiếp xúc với Internet hoặc chúng được hiển thị qua proxy HTTP hoặc HTTPS. Trong môi trường OpenShift, định nghĩa máy proxy này được đặt làm biến môi trường.

Điều này có thể được thực hiện bằng cách thêm định nghĩa proxy trên tệp chính và tệp nút nằm dưới /etc/sysconfig. Điều này tương tự như chúng tôi làm cho bất kỳ ứng dụng nào khác.

Máy chính

/ etc / sysconfig / openshift-master

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

Máy nút

/ etc / sysconfig / openshift-node

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

Sau khi hoàn tất, chúng ta cần khởi động lại máy chủ và máy nút.

Đối với Docker Pull

/ etc / sysconfig / docker

HTTP_PROXY = http://USERNAME:[email protected]:8080/
HTTPS_PROXY = https://USERNAME:[email protected]:8080/
NO_PROXY = master.vklnld1446.int.example.com

Để làm cho một nhóm chạy trong môi trường proxy, nó có thể được thực hiện bằng cách sử dụng:

containers:
- env:
   - name: "HTTP_PROXY"
      value: "http://USER:PASSWORD@:10.0.1.1:8080"

Lệnh OC môi trường có thể được sử dụng để cập nhật env hiện có.

OpenShift Storage với NFS

Trong OpenShift, khái niệm khối lượng liên tục và yêu cầu khối lượng liên tục tạo thành bộ nhớ liên tục. Đây là một trong những khái niệm chính trong đó tập liên tục đầu tiên được tạo ra và sau đó là tập tương tự được xác nhận. Đối với điều này, chúng ta cần có đủ dung lượng và không gian đĩa trên phần cứng bên dưới.

apiVersion: v1
kind: PersistentVolume
metadata:
   name: storage-unit1
spec:
   capacity:
      storage: 10Gi
   accessModes:
   - ReadWriteOnce
   nfs:
      path: /opt
      server: 10.12.2.2
   persistentVolumeReclaimPolicy: Recycle

Tiếp theo, sử dụng lệnh OC create tạo Ổ đĩa liên tục.

$ oc create -f storage-unit1.yaml

persistentvolume " storage-unit1 " created

Yêu cầu khối lượng đã tạo.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
   name: Storage-clame1
spec:
   accessModes:
      - ReadWriteOnce
   resources:
      requests:
         storage: 5Gi

Tạo xác nhận quyền sở hữu.

$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created

Quản lý Người dùng và Vai trò

Quản trị vai trò và người dùng được sử dụng để quản lý người dùng, quyền truy cập và kiểm soát của họ trên các dự án khác nhau.

Tạo người dùng

Các mẫu được xác định trước có thể được sử dụng để tạo người dùng mới trong OpenShift.

kind: "Template"
apiVersion: "v1"
parameters:
   - name: vipin
   required: true
objects:
   - kind: "User"
   apiVersion: "v1"
   metadata:
   name: "${email}" - kind: "Identity" apiVersion: "v1" metadata: name: "vipin:${email}"
   providerName: "SAML"
   providerUserName: "${email}" - kind: "UserIdentityMapping" apiVersion: "v1" identity: name: "vipin:${email}"
user:
   name: "${email}"

Sử dụng oc create –f <tên tệp> để tạo người dùng.

$ oc create –f vipin.yaml

Sử dụng lệnh sau để xóa người dùng trong OpenShift.

$ oc delete user <user name>

Giới hạn quyền truy cập của người dùng

ResourceQuotas và LimitRanges được sử dụng để giới hạn mức độ truy cập của người dùng. Chúng được sử dụng để giới hạn các vỏ và thùng chứa trên cụm.

apiVersion: v1
kind: ResourceQuota
metadata:
   name: resources-utilization
spec:
   hard:
      pods: "10"

Tạo báo giá bằng cách sử dụng cấu hình trên

$ oc create -f resource-quota.yaml –n –Openshift-sample

Mô tả báo giá tài nguyên

$ oc describe quota resource-quota  -n  Openshift-sample
Name:              resource-quota
Namespace:                              Openshift-sample
Resource           Used                  Hard
--------           ----                  ----
pods                3                    10

Việc xác định giới hạn vùng chứa có thể được sử dụng để giới hạn tài nguyên sẽ được sử dụng bởi các vùng chứa đã triển khai. Chúng được sử dụng để xác định giới hạn tối đa và tối thiểu của các đối tượng nhất định.

Giới hạn dự án của người dùng

Điều này về cơ bản được sử dụng cho số lượng dự án mà người dùng có thể có tại bất kỳ thời điểm nào. Về cơ bản, chúng được thực hiện bằng cách xác định cấp độ người dùng trong các danh mục đồng, bạc và vàng.

Trước tiên, chúng ta cần xác định một đối tượng có giá trị bao nhiêu dự án mà một loại đồng, bạc và vàng có thể có. Chúng cần được thực hiện trong tệp master-confif.yaml.

admissionConfig:
   pluginConfig:
      ProjectRequestLimit:
         configuration:
            apiVersion: v1
            kind: ProjectRequestLimitConfig
            limits:
            - selector:
               level: platinum
            - selector:
               level: gold
            maxProjects: 15
            - selector:
               level: silver
            maxProjects: 10
            - selector:
               level: bronze
            maxProjects: 5

Khởi động lại máy chủ chính.

Chỉ định người dùng cho một cấp cụ thể.

$ oc label user vipin level = gold

Di chuyển người dùng ra khỏi nhãn, nếu được yêu cầu.

$ oc label user <user_name> level-

Thêm vai trò cho người dùng.

$ oadm policy add-role-to-user 
      
        <user_name>

Xóa vai trò khỏi người dùng.

$ oadm policy remove-role-from-user 
      
        <user_name>

Thêm vai trò cụm cho người dùng.

$ oadm policy add-cluster-role-to-user 
      
        <user_name>

Xóa vai trò cụm khỏi người dùng.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name>

Thêm một vai trò vào một nhóm.

$ oadm policy add-role-to-user 
      
        <user_name>

Xóa vai trò khỏi nhóm.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name>

Thêm một vai trò cụm vào một nhóm.

$ oadm policy add-cluster-role-to-group 
      
        <groupname>

Xóa vai trò cụm khỏi một nhóm.

$ oadm policy remove-cluster-role-from-group <role> <groupname>

Người dùng quản trị cụm

Đây là một trong những vai trò mạnh mẽ nhất mà người dùng có khả năng quản lý một cụm hoàn chỉnh bắt đầu từ khi tạo cho đến khi xóa một cụm.

$ oadm policy add-role-to-user admin <user_name> -n <project_name>

Người dùng có sức mạnh tối thượng

$ oadm policy add-cluster-role-to-user cluster-admin <user_name>

OpenShift được xây dựng dựa trên Docker và Kubernetes. Tất cả các vùng chứa được xây dựng trên cụm Docker, về cơ bản là dịch vụ Kubernetes trên các máy Linux, sử dụng tính năng dàn nhạc Kubernetes.

Trong quá trình này, chúng tôi xây dựng Kubernetes master điều khiển tất cả các nút và triển khai các vùng chứa cho tất cả các nút. Chức năng chính của Kubernetes là kiểm soát cụm OpenShift và luồng triển khai bằng cách sử dụng một loại tệp cấu hình khác. Như trong Kubernetes, chúng tôi sử dụng kubctl giống như cách chúng tôi sử dụng tiện ích dòng lệnh OC để xây dựng và triển khai các vùng chứa trên các nút cụm.

Sau đây là các loại tệp cấu hình khác nhau được sử dụng để tạo các loại đối tượng khác nhau trong cụm.

  • Images
  • POD
  • Service
  • Bộ điều khiển sao chép
  • Bộ bản sao
  • Deployment

Hình ảnh

Hình ảnh Kubernetes (Docker) là các khối xây dựng chính của Cơ sở hạ tầng được chứa đựng. Hiện tại, Kubernetes chỉ hỗ trợDockerhình ảnh. Mỗi vùng chứa trong một nhóm có hình ảnh Docker của nó chạy bên trong nó.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
   containers:
- name: neo4j-server ------------------------> 2
image: <Name of the Docker image>----------> 3
imagePullPolicy: Always ------------->4
command: [“echo”, “SUCCESS”] -------------------> 5

POD

Một nhóm là tập hợp các vùng chứa và bộ lưu trữ của nó bên trong một nút của cụm Kubernetes. Có thể tạo một nhóm với nhiều vùng chứa bên trong nó. Sau đây là một ví dụ về việc giữ một vùng chứa cơ sở dữ liệu và vùng chứa giao diện web trong cùng một nhóm.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
      image: tomcat: 8.0
      ports:
- containerPort: 7500
imagePullPolicy: Always

Dịch vụ

Một dịch vụ có thể được định nghĩa là một tập hợp các nhóm hợp lý. Nó có thể được định nghĩa là một phần trừu tượng trên đầu nhóm cung cấp một địa chỉ IP và tên DNS duy nhất mà các nhóm có thể được truy cập. Với Service, rất dễ dàng quản lý cấu hình cân bằng tải. Nó giúp POD mở rộng quy mô rất dễ dàng.

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
      targetPort: 31999

Bộ điều khiển sao chép

Bộ điều khiển nhân bản là một trong những tính năng chính của Kubernetes, chịu trách nhiệm quản lý vòng đời nhóm. Nó chịu trách nhiệm đảm bảo rằng số lượng bản sao nhóm được chỉ định đang chạy tại bất kỳ thời điểm nào.

apiVersion: v1
kind: ReplicationController
metadata:
   name: Tomcat-ReplicationController
spec:
   replicas: 3
   template:
   metadata:
      name: Tomcat-ReplicationController
   labels:
      app: App
      component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

Bộ bản sao

Bộ bản sao đảm bảo có bao nhiêu bản sao của nhóm sẽ được chạy. Nó có thể được coi là một sự thay thế của bộ điều khiển nhân bản.

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
      tier: Backend
   matchExpression:
      - { key: tier, operation: In, values: [Backend]}
   
   app: App
   component: neo4j
spec:
   containers:
   - name: Tomcat-
image: tomcat: 8.0
   ports:
containerPort: 7474

Triển khai

Các triển khai được nâng cấp và các phiên bản cao hơn của bộ điều khiển nhân rộng. Họ quản lý việc triển khai các bộ bản sao, đây cũng là một phiên bản nâng cấp của bộ điều khiển sao chép. Chúng có khả năng cập nhật tập hợp bản sao và chúng cũng có khả năng quay trở lại phiên bản trước đó.

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
lables:
   app: Tomcat-ReplicaSet
   tier: Backend
spec:
   containers:
name: Tomcat-
   image: tomcat: 8.0
   ports:
   - containerPort: 7474

Tất cả các tệp cấu hình có thể được sử dụng để tạo các đối tượng Kubernetes tương ứng của chúng.

$ Kubectl create –f <file name>.yaml

Các lệnh sau có thể được sử dụng để biết chi tiết và mô tả của các đối tượng Kubernetes.

For POD

$ Kubectl get pod <pod name> $ kubectl delete pod <pod name>
$ kubectl describe pod <pod name>

For Replication Controller

$ Kubectl get rc <rc name>
$ kubectl delete rc <rc name> $ kubectl describe rc <rc name>

For Service

$ Kubectl get svc <svc name> $ kubectl delete svc <svc name>
$ kubectl describe svc <svc name>

Để biết thêm chi tiết về cách làm việc với Docker và Kubernetes, vui lòng truy cập hướng dẫn Kubernetes của chúng tôi bằng cách sử dụng kubernetes liên kết sau .

Bảo mật OpenShift chủ yếu là sự kết hợp của hai thành phần chủ yếu xử lý các ràng buộc bảo mật.

  • Ràng buộc về ngữ cảnh bảo mật (SCC)
  • Tài khoản dịch vụ

Ràng buộc về ngữ cảnh bảo mật (SCC)

Về cơ bản, nó được sử dụng để hạn chế nhóm, có nghĩa là nó xác định các giới hạn cho nhóm, như những hành động mà nó có thể thực hiện và tất cả những thứ nó có thể truy cập trong cụm.

OpenShift cung cấp một bộ SCC được xác định trước có thể được quản trị viên sử dụng, sửa đổi và mở rộng.

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

Nếu ai đó muốn sử dụng bất kỳ scc nào được xác định trước, điều đó có thể được thực hiện bằng cách thêm người dùng hoặc nhóm vào nhóm scc.

$ oadm policy add-user-to-scc <scc_name> <user_name> $ oadm policy add-group-to-scc <scc_name> <group_name>

Tài khoản dịch vụ

Tài khoản dịch vụ về cơ bản được sử dụng để kiểm soát quyền truy cập vào API chính OpenShift, được gọi khi lệnh hoặc yêu cầu được kích hoạt từ bất kỳ máy chủ hoặc máy nút nào.

Bất kỳ lúc nào một ứng dụng hoặc một quy trình yêu cầu khả năng không được cấp bởi SCC hạn chế, bạn sẽ phải tạo một tài khoản dịch vụ cụ thể và thêm tài khoản vào SCC tương ứng. Tuy nhiên, nếu một SCC không phù hợp với yêu cầu của bạn, thì tốt hơn là tạo một SCC mới cụ thể cho yêu cầu của bạn hơn là sử dụng một SCC phù hợp nhất. Cuối cùng, hãy đặt nó cho cấu hình triển khai.

$ oc create serviceaccount Cadmin $ oc adm policy add-scc-to-user vipin -z Cadmin

An ninh vùng chứa

Trong OpenShift, bảo mật của các vùng chứa dựa trên khái niệm về mức độ an toàn của nền tảng vùng chứa và các vùng chứa đang chạy ở đâu. Có rất nhiều điều xuất hiện khi chúng ta nói về an ninh vùng chứa và những gì cần được quan tâm.

Image Provenance - Có hệ thống ghi nhãn an toàn để xác định chính xác và không thể chối cãi được nguồn gốc của các thùng chứa chạy trong môi trường sản xuất.

Security Scanning - Một máy quét hình ảnh tự động kiểm tra tất cả các hình ảnh để tìm các lỗ hổng đã biết.

Auditing - Môi trường sản xuất thường xuyên được kiểm tra để đảm bảo tất cả các thùng chứa đều dựa trên các thùng chứa cập nhật và cả máy chủ và thùng chứa đều được định cấu hình an toàn.

Isolation and Least Privilege- Các vùng chứa chạy với tài nguyên và đặc quyền tối thiểu cần thiết để hoạt động hiệu quả. Chúng không thể can thiệp quá mức vào máy chủ hoặc các vùng chứa khác.

Runtime Threat Detection - Khả năng phát hiện các mối đe dọa đang hoạt động chống lại ứng dụng được lưu trữ trong thời gian chạy và tự động phản hồi nó.

Access Controls - Các mô-đun bảo mật của Linux, chẳng hạn như AppArmor hoặc SELinux, được sử dụng để thực thi các kiểm soát truy cập.

Có một số phương pháp quan trọng mà bảo mật vùng chứa được lưu trữ.

  • Kiểm soát quyền truy cập qua oAuth
  • Qua bảng điều khiển web tự phục vụ
  • Bằng chứng chỉ của nền tảng

Kiểm soát quyền truy cập qua OAuth

Trong phương pháp này, xác thực đối với quyền truy cập điều khiển API được lưu trữ bằng cách nhận mã thông báo bảo mật để xác thực thông qua máy chủ OAuth, có sẵn trong máy chủ OpenShift. Là quản trị viên, bạn có khả năng sửa đổi cấu hình cấu hình máy chủ OAuth.

Để biết thêm chi tiết về cấu hình máy chủ OAuth, hãy tham khảo Chương 5 của hướng dẫn này.

Qua Bảng điều khiển Web Tự phục vụ

Tính năng bảo mật bảng điều khiển web này được tích hợp sẵn trong bảng điều khiển web OpenShift. Bảng điều khiển này đảm bảo rằng tất cả các nhóm làm việc cùng nhau không có quyền truy cập vào các môi trường khác mà không có xác thực. Master multi-telnet trong OpenShift có các tính năng bảo mật sau:

  • Lớp TCL được bật
  • Sử dụng chứng chỉ x.509 để xác thực
  • Bảo mật cấu hình etcd trên máy chủ

Bằng chứng nhận của nền tảng

Trong phương pháp này, các chứng chỉ cho từng máy chủ được cấu hình trong quá trình cài đặt thông qua Ansible. Vì nó sử dụng giao thức truyền thông HTTPS thông qua Rest API, chúng tôi cần kết nối bảo mật TCL với các thành phần và đối tượng khác nhau. Đây là những chứng chỉ được xác định trước, tuy nhiên, người ta thậm chí có thể cài đặt chứng chỉ tùy chỉnh trên cụm chủ để truy cập. Trong quá trình thiết lập ban đầu của chính, các chứng chỉ tùy chỉnh có thể được định cấu hình bằng cách ghi đè các chứng chỉ hiện có bằng cách sử dụngopenshift_master_overwrite_named_certificates tham số.

Example

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

Để biết thêm chi tiết về cách tạo chứng chỉ tùy chỉnh, hãy truy cập liên kết sau:

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

An ninh mạng

Trong OpenShift, Mạng do Phần mềm Xác định (SDN) được sử dụng để liên lạc. Không gian tên mạng được sử dụng cho mỗi nhóm trong cụm, trong đó mỗi nhóm có IP riêng và một loạt các cổng để nhận lưu lượng mạng trên đó. Bằng phương pháp này, người ta có thể cô lập các nhóm vì nó không thể giao tiếp với các nhóm trong dự án khác.

Cô lập một dự án

Điều này có thể được thực hiện bởi quản trị viên cụm bằng cách sử dụng sau oadm command từ CLI.

$ oadm pod-network isolate-projects <project name 1> <project name 2>

Điều này có nghĩa là các dự án được xác định ở trên không thể giao tiếp với các dự án khác trong cụm.

Bảo mật số lượng

Bảo mật khối lượng rõ ràng có nghĩa là bảo mật PV và PVC của các dự án trong cụm OpenShift. Chủ yếu có bốn phần để kiểm soát quyền truy cập vào các ổ đĩa trong OpenShift.

  • Nhóm bổ sung
  • fsGroup
  • runAsUser
  • seLinuxOptions

Nhóm bổ sung - Nhóm bổ sung là các nhóm Linux thông thường. Khi một tiến trình chạy trong hệ thống, nó sẽ chạy với ID người dùng và ID nhóm. Các nhóm này được sử dụng để kiểm soát quyền truy cập vào bộ nhớ dùng chung.

Kiểm tra gắn kết NFS bằng lệnh sau.

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

Kiểm tra chi tiết NFS trên máy chủ gắn kết bằng lệnh sau.

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

Các / opt / nfs / xuất khẩu có thể truy cập bằng cách UID454265 và nhóm 2325.

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup là viết tắt của nhóm hệ thống tệp được sử dụng để thêm nhóm bổ sung vùng chứa. ID nhóm bổ sung được sử dụng để lưu trữ chia sẻ và fsGroup được sử dụng để lưu trữ khối.

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

runAsUser

runAsUser sử dụng ID người dùng để giao tiếp. Điều này được sử dụng để xác định hình ảnh vùng chứa trong định nghĩa nhóm. Một người dùng ID duy nhất có thể được sử dụng trong tất cả các vùng chứa, nếu được yêu cầu.

Trong khi chạy vùng chứa, ID đã xác định được khớp với ID chủ sở hữu khi xuất. Nếu ID được chỉ định được xác định bên ngoài, thì nó sẽ trở thành chung cho tất cả các vùng chứa trong nhóm. Nếu nó được xác định với một nhóm cụ thể, thì nó sẽ trở thành cụ thể cho một vùng chứa.

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265
ja/tutorial
es/tutorial
de/tutorial
fr/tutorial
th/tutorial
pt/tutorial
ru/tutorial
vi/tutorial
it/tutorial
ko/tutorial
tr/tutorial
id/tutorial
pl/tutorial
hi/tutorial
japost
espost
depost
frpost
thpost
ptpost
rupost
vipost
itpost
kopost
trpost
idpost
plpost
hipost

© Copyright 2021 - 2024 | All Rights Reserved