HomeIDE

Hướng dẫn sử dụng Gitlab

Like Tweet Pin it Share Share Email

Lịch sử Gitlab?

Phát triển bởi Dmitriy Zaporozhets đến từ đất nước Ukraine và hiện là giám đốc điều hành Sytse Sijbrandij có trụ sử tại Utrecht và được viết bằng ngôn ngữ Ruby với giấy phép phần mềm tự do và nguồn mở MIT và cho đến nay nó đã được các nhà đầu tư như Alibaba Group, IBM, Spacex và Khosla Ventures tài trợ.

Hiện nó cũng đang được sử dụng bởi hơn 100.000 tổ chức bao gồm Trung tâm nghiên cứu Jülich Research Center, NASA, Alibaba, Invincea, O’Reilly Media, Leibniz-Rechenzentrum (LRZ), CERN,… sử dụng để làm nơi lưu trữ và hiện có hơn 1000 mã nguồn mở có mặt trên Gitlab.

Điểm đặc biệt của Gitlab là bạn có thể tải về gói cài đặt và cài lên máy chủ riêng. Chính vì vậy hiện nay có rất nhiều đơn vị sử dụng GitLab cài lên máy chủ riêng để tiện bề quản lý sử dụng cũng như đảm bảo tốc độ kết nối theo khuôn khổ riêng. GitLab cũng hoàn toàn phù hợp cho cả người dùng cá nhân nếu như bạ có VPS sử dụng để làm kho code và hơn hết khi bạn cài đặt GitLab trên VPS bạn không cần phải cài thêm nhiều thứ khác mà chỉ cần đảm bảo hệ điều hành máy chủ Linux là có thể cài đặt được.

GitLab là gì?

  • GitLab khá nổi tiếng và là một mã nguồn mở của máy chủ Git được thực hiện bởi hơn 50.000 tổ chức. Trong vài năm gần đây Gitlad đã phát triển mạnh mẽ với sự hỗ trợ của cộng đồng mạng, hàng nghìn người sử dụng trên một máy chủ duy nhất hoặc một số máy chủ hoạt động tương tự. Nếu bạn cần thiết lập một máy chủ Git, thì GitLab cung cấp cho bạn một giải pháp hoàn hảo.
  • Gitlad là một hệ thống self-hosted để quản lý mã nguồn của bạn. Bản đầu tiên được phát hành vào tháng 10/2011 và được cập nhật vào ngày 22 hàng tháng. Gitlab được phát hành theo tiêu chuẩn của MIT.
  • Gitlab được thành lập bởi Dmitriy Zaporozhets năm 2013. Dự án bao gồm hai nhóm chính: một bên là “open source core team” và một bên là “GitLab B.V. team” (chi nhánh của công ty Gitlab).
  • GitLab được sử dụng để lưu trữ trên Github, nhưng với sự nỗ lực của Dmitriy Zaporozhets suốt một năm làm việc tại GitLab, kể từ tháng 1/2014 mã nguồn được lưu trữ trên sever chính của gitlab là gitlab.com. Các nhánh của GitLab được lưu trữ trên github, sẽ hoạt động như một source, nơi bạn có thể pull, push và merge các yêu cầu.

GitLab hỗ trợ ba phiên bản

  • Gitlab community editon (CE) – Gitlab phiên bản cộng đồng: là phiên bản mã nguồn mở. Được cung cấp qua Git từ kho lưu trữ chứa gitlab. Phiên bản mới nhất của gitlab được các nhà phát triển release tại các nhánh stable và nhánh master 
  • Gitlad enterprise edition (EE) – Gitlab phiên bản doanh nghiệp: là phiên bản có sẵn không lâu sau khi phát hành bản CE, được cung cấp từ kho lưu trữ của gitlab.com. Một doanh nghiệp đăng lý GitLab được sự support của GitLad BV những khó khăn khi cài đặt.
  • Gitlab continuous intergration (CI): là một giải pháp tích hợp được thực hiện bở nhóm phát triển Gitlab

Protected branches:

  • Gitlab cho phép đọc hoặc ghi vào repository và các branches.
  • Để cấp quyền cho những người được phép commit và pushing code, gitlad đã tạo ra protected branches.
  • Một protected branch gồm 3 điều cơ bản sau:
    • Ngăn chặn việc push từ tất cả mọi người trừ user và master.
    • Ngăn chặn việc push code lên branch từ những người không có quyền truy cập.
    • Ngăn chặn bất kỳ ai thực hiện xóa branch.
  • Bạn có thể tạo bất kỳ branch từ một protected branch. Gitlad mặc định master branch là protected branch.
  • Để bảo mật một branch, user cần có ít nhất một quyền cho phép từ master branch.

Tầng vật lý của GitLab

  • Kho lưu trữ: xử lý các dự án trong Gitlab. Các sản phẩm lưu trữ (như dự án) có thể được lưu trữ tại warehouse. Nó có thể là một đĩa cứng hoặc một cái gì đó phức tạp hơn như hệ thống tập tin NFS.
  • Nginx hoạt động giống như front-desk. Người sử dụng đến Nginx và yêu cầu hành động được thực hiện bởi worker trong văn phòng.
  • Cơ sở dữ liệu là một loạt các file của các metal file cabinets với các thông tin về:
  • Các sản phẩm trong warehouse (siêu dữ liệu, issuse, các yêu cầu merge …).
  • Người sử dụng đến front-desk (permissions).
  • Redis: là phần giao tiếp một broad với cubby holes- cái mà có thể chứa các nhiệm vụ, yêu cầu cho worker.
  • Sidekiq là một worker, công việc chủ yếu là xử lý việc gửi email. Nó nhận nhiệm vụ từ Redis.
  • A Unicorn worker: là một nhân viên xử lý các nhiệm vụ nhanh chóng và dễ. Học làm việc với Redis. Công việc của họ gồm:
  • Kiểm tra quyền truy cập bằng cách kiểm tra các session của người dùng được lưu trữ trong Redis cubby hole.
  • Làm nhiệm vụ cho Sidekiq.
  • Lấy công cụ từ warehouse hoặc di chuyển mọi thứ xung quanh trong đó
  • Gitlab-shell: là loại thứ ba của worker, nhiệm vụ của nó là tạo các đơn đặt hàng từ một máy fax (SSH) thay vì front-desk (HTTP). Gitlab-shell giao tiếp với Sidekiq qua Redis và hỏi những câu hỏi nhanh của Unicorn worker hoặc trực tiếp hoặc qua front-desk.
  • Gitlab enterprise edition (ứng dụng) là tập hợp các quy trình và hoạt động kinh doanh được điểu hành bởi ofice (văn phòng).

System layout

  • Khi đề cập đến Git trong những hình ảnh có nghĩa là thư mục home của người sử dụng Git thường là /home/git.
  • Repositories bare nằm trong đường dẫn /home/git/repositories. Gitlab là một ứng dụng ruby on ralis do đó để biết rõ các hoạt động bên trong bạn có thể tìm hiểu bằng cách tìm hiểu về hoạt động của ruby on ralis.
  • Để sử dụng kho dữ liệu qua SSH có một ứng dụng thêm vào được gọi là gitlab-sell cái mà được cài đặt tại /home/git/gitlab-shell.

Components

Điều kiện cài đặt Gitlab

Hầu hết các máy chủ hệ điều hành mới hiện nay đều đáp ứng tốt nhu cầu.
+) Một CPU có một hoặc 2 nhân
+) RAM: 1GB hoặc 2GB trở lên – càng cao càng tốt
+) Cần kết nối internet
Các hệ điều hành cài đặt thông dụng nhất: Ubuntu >= 12.03 64 bit; centos 6, centos7 … chi tiết cài đặt bài hướng dẫn sau mình sẽ hướng dẫn chi tiết.

Managing Users, Groups and Permissions

Gitlab có nền tảng trên tương tác người dùng, nhưng bạn muốn có những điều khiển trên tất cả quyền các người dùng trên toàn bộ hệ thống. Trong phần này chúng ta sẽ tìm hiểu về quản lý người dùng của gitlab, chúng ta sẽ thấy sự khác nhau giữa các kiểu người dùng mà chúng ta có thể thêm vào project, làm sao để quản lý các nhóm mà chúng ta quản trị và làm thế nào để bảo mật được dự án của chúng ta từ những push sai và những ánh mắt tò mò khác.

1. Thêm một người dùng:

  • Khi nhóm phát triển của bạn càng ngày càng lớn dần thì việc thêm các người dùng khác vào dự án là một việc cần thiết. Ở đây chúng ta sẽ giới thiệu việc gửi một lời mời tới một người dùng khác để tham gia vào dự án.
  • Khi thêm một người dùng chúng ta thêm các thông tin cơ bản của người dùng mới vào, tuy nhiên chúng ta cũng có thể thêm nhiều thông tin khác như ảnh của người dùng, tài khoản Skype, tài khoản Linkedln, tài khoản Twitter nếu bạn muốn. Nhưng điều cần chú ý đặc biệt chính là ảnh đại diện của người dùng mới. Nó sẽ được hiển thị mỗi lần người dùng có tương tác với dự án. Ảnh đại diện sẽ được hiển thị ngay cạnh tên người dùng để các thành viên trong cùng một dự án có thể nhìn thấy. Còn các thông tin khác sẽ được hiển thị trong trang hồ sơ của người dùng mới.
  • Ngoài ra bạn cũng có thể giới hạn số người dùng có thể tham gia vào dự án của bạn. Điều này là hữu ích nếu bạn không muốn tất cả người dùng có một massive amount of private project. Tuy nhiên một người dùng thì không có giới hạn số dự án có thể tham gia.Chúng ta sẽ bỏ cờ Admin đối với người dùng mới này. Điều này đảm bảo việc người dùng mới này không có quyền ngang với bạn hay người dùng mới này không có quyền admin để có toàn quyền trong các việc điều khiển đối với GitLab của bạn.
  • Chúng ta không thêm mật khẩu vào khi đăng kí vì mật khẩu sẽ được Gitlab sinh tự động gửi kèm với email thư mời người dùng mới. Như vậy chúng ta cần thiết phải đổi mật khẩu ngay khi chúng ta đăng nhập lần đầu tiên.

2. Tạo một nhóm mới

  • Trong phần này giới thiệu việc chúng ta sẽ tạo một nhóm mới. Các nhóm có thể được sử dụng là không gian mà bạn có thể đặt dự án của bạn vào đó. Bạn cũng có thể phân quyền cho các người dùng trong một nhóm. Khi bạn tạo một dự án mới trong một nhóm thì các người dùng trong nhóm sẽ tự động được cấp quyền truy cập vào dự án.
  • Nhóm chính là một cách để gitlab giới thiệu không gian lưu trữ cho các dự án của bạn. Nếu dự án của bạn có nhiều repositories, bạn có thể tạo riêng một nhóm cho dự án này. Sau đó thêm tất cả các repositories vào trong nhóm mới tạo. Lợi ích của việc này là bạn không cần phải thêm các người dùng vào repositories mà người dùng trong một nhóm sẽ tự động được thêm vào tất cả các repositories.
  • Ngay sau khi bạn tạo một nhóm mới thì bạn sẽ tự động được cấp quyền Owner. Với những người dùng mới khi được thêm vào nhóm thì sẽ có năm mức truy nhập vào nhóm là: Guest, Reporter, Master, Developer và Owner. Chỉ có Master và Owner là có thêm các quyền truy nhập trong nhóm.
  • Master có thể tạo các dự án trong một nhóm. Owner có sửa hoặc xoá một nhóm và quản lý các người dùng trong nhóm.

3. Working with user permissions

  • Bạn có thể không muốn tất cả người dùng trong hệ thống của bạn đều được cấp quyền là một người quản trị hay bạn có một dự án mà bạn chỉ muốn người dùng chỉ có thể tạo ra các issue chứ không có khả năng commit code. Trong một số trường hợp này bạn cần sử dụng tới model phân quyền của gitlab.
  • Trong Gitlab bạn có thể bạn có thể bảo vệ dự án của bạn bằng cách dùng user permissions. Có 5 mức quyền khác nhau là Guest, Reporter, Developer, Master và Owner. Owner là mức phân quyền cao nhất mà bạn không thể cấp cho bất kỳ một người dùng nào khác. Người dùng tạo ra dự án này thì tự động được cấp quyền này.
  • Các hoạt động mà mỗi mức quyền được phép thực hiện của 5 mức là:

| |Guest | Reporter |Developer | Master|Owner | |—|—|—|—|—| | Tạo một issue | * | * | * | * |* | Để lại ocmment | * | * | * | * |* | Pull code của dự án | | * | * | * |* | Tải dự án | | * | * | * |* | Tạo một code snippets | | * | * | * |* | Tạo một merge request | | | * | * |* | Push thay đổi vào một nhánh không được bảo vệ | | | * | * |* Xoá một nhánh không được bảo vệ | | | * | * |* | Thêm Tags | | | * | * |* | Viết Wiki| | | * | * |* | Quản lý issue tracker | | | * | * |* | Thêm một nhóm người dung mới | | | | * |* | Push thay đổi vào nhánh được bảo vệ | | | | * |* | Quản lý nhánh được bảo vệ | | | | * |* | Quản lý Git tags | | | | * |* |Sửa chữa dự án | | | | * |* |Thêm deploy key vào dự án | | | | * |* | Cấu hình dự án| | | | * |*

4. protecting your main branches

  • Bạn có thể muốn bảo vệ nhánh quan trọng nhất của bạn tránh các việc push sự thay đổi không mong muốn ở nhánh này, hay những push sự thay đổi trực tiếp vào nhánh này mà không có sự thông báo bởi các người dùng khác
  • Bảo vệ một nhánh có thể thực hiện trong Gitlab bằng việc đánh dấu nhánh ấy là Protected điều này có nghĩa là với những người dùng được cấp quyền developer và thấp hơn quyền này không có thể thực hiện được việc điều hướng push sự thay đổi vào thẳng nhánh này. Như thế thì nếu người dùng muốn push sự thay đổi vào nhánh này thì cần phải tạo các merge request để có thể push sự thay đổi vào các branch này.
  • Một số nhánh bạn cần nên làm theo điều này là các nhánh Master, Acceptance và Production. Bạn không muốn người dùng commit trên các nhánh này hay push các thay đổi vào thẳng các nhánh này. Một điều thú vị cho việc này chính là bạn có thể bảo vệ được các nhánh này tránh khỏi các tai nạn không may như việc xoá mất một branch.

5. Configuring the project’s visibility

  • Gitlab cho phép bạn có ba kiểu project: Private, Internal, và Public
  • Khi bạn có một dự án Public thì mọi người đều có thể xem dự án dù họ không có tài khoản trên hệ thống của bạn. Mọi người không cần có tài khoản trên hệ thống vẫn có thể pull code về. Người dùng có tài khoản trên hệ thống của bạn mặc dù không được chấp nhận truy cập nhưng vẫn có thể tạo được các merge request hoặc mở một issue.
  • Như đã biết thì Gitlab cung cấp 3 kiểu project và mặc định của nó là Private. Các dự án Private là những dự án mà chỉ hiển thị với các người dung đã được thêm vào dự án.The amount of options an invited person in your project has depends on the permissions you grant them.
  • Nếu bạn có một dự án mà có thể cho phép tất cả các người dùng có có tài khoản trong hệ thống Gitlab của bạn thì bạn có thể để Internal. Một số người dùng đã đăng nhập sẽ được phân quyền Guest
  • Kiểu cuối cùng chính là Public. Một dự án Public có thể được sao chép từ bởi bất kì một người dùng nào khác mà không cần có các xác thực.

Comments (0)

Leave a Reply

Your email address will not be published. Required fields are marked *