ProHoster > බ්ලොග් > පරිපාලනය > GIT සේවාදායකයට බහු-පරිශීලක ප්රවේශය සංවිධානය කිරීම

GIT සේවාදායකයට බහු-පරිශීලක ප්රවේශය සංවිධානය කිරීම

Git සේවාදායකයක් ස්ථාපනය කිරීමේදී සහ වින්‍යාස කිරීමේදී, පරිශීලකයින් කිහිප දෙනෙකුට ව්‍යාපෘති කිහිපයකට ප්‍රවේශය සංවිධානය කිරීම පිළිබඳ ප්‍රශ්නය පැන නගී. මම ගැටලුව ගැන පර්යේෂණ කර මගේ සියලු අවශ්‍යතා සපුරාලන විසඳුමක් සොයා ගත්තෙමි: සරල, ආරක්ෂිත, විශ්වාසදායක.

මගේ පැතුම් මෙසේය.

  • සෑම පරිශීලකයෙක්ම තමන්ගේම ගිණුමක් සමඟ සම්බන්ධ වේ
  • පරිශීලකයින් කිහිප දෙනෙකුට එක් ව්යාපෘතියක් මත වැඩ කළ හැකිය
  • එකම පරිශීලකයෙකුට ව්‍යාපෘති කිහිපයක් මත වැඩ කළ හැක
  • සෑම පරිශීලකයෙකුටම ප්‍රවේශය ඇත්තේ ඔහු වැඩ කරන ව්‍යාපෘති සඳහා පමණි
  • යම් ආකාරයක වෙබ් අතුරු මුහුණතක් හරහා පමණක් නොව, විධාන රේඛාව හරහා සම්බන්ධ වීමට හැකි විය යුතුය

එය ද විශිෂ්ට වනු ඇත:

  • පුද්ගලයන් පාලනය කිරීම සඳහා කියවීමට පමණක් අවසර ලබා දෙන්න
  • Git හි පරිශීලක ප්‍රවේශ අයිතිවාසිකම් පහසුවෙන් කළමනාකරණය කරන්න

GIT සේවාදායකයට ප්‍රවේශ වීමට හැකි විකල්ප පිළිබඳ දළ විශ්ලේෂණය

පළමුවෙන්ම, ඔබ තෝරාගත යුත්තේ කුමක් දැයි දැන ගැනීමට අවශ්‍ය වේ, එබැවින් Git ප්‍රොටෝකෝල පිළිබඳ ඉක්මන් දළ විශ්ලේෂණයක් මෙන්න.

  • ssh - සේවාදායකයට ප්‍රවේශ වීම සඳහා විශේෂයෙන් සාදන ලද පරිශීලක ගිණුමක් භාවිතා කරයි.
    • Git සියළුම නිධි වලට ප්‍රවේශ වීමට එක් ගිණුමක් භාවිතා කිරීම එහි නිර්දේශ වලින් බැහැර නොකිරීම පුදුමයකි. මෙය කිසිසේත්ම මගේ අවශ්‍යතා සපුරාලන්නේ නැත.
    • ඔබට ගිණුම් කිහිපයක් භාවිතා කළ හැක, නමුත් ඔබට ඇතැම් නාමාවලි වලට පමණක් පරිශීලක ප්‍රවේශය සීමා කළ හැක්කේ කෙසේද?
      • වෙනත් පරිශීලකයින් සඳහා එහි ලිවීමේ ප්‍රවේශය සංවිධානය කිරීම අපහසු බැවින් මුල් නාමාවලිය වසා දැමීම සුදුසු නොවේ
      • Git ඒවා සබැඳි ලෙස අර්ථකථනය නොකරන නිසා ඔබේ මුල් නාමාවලියෙන් symlinks භාවිතා කිරීම ද අපහසු වේ
      • පරිවර්තකයාට ප්රවේශය සීමා කළ හැකි නමුත් එය සැමවිටම ක්රියා කරන බවට පූර්ණ සහතිකයක් නොමැත
        • ඔබට සාමාන්‍යයෙන් එවැනි පරිශීලකයින් සඳහා ඔබේම විධාන පරිවර්තකය සම්බන්ධ කළ හැකිය, නමුත්
          • පළමුව, මෙය දැනටමත් යම් ආකාරයක දුෂ්කර තීරණයකි,
          • දෙවනුව, මෙය මග හැරිය හැක.

    නමුත් සමහර විට පරිශීලකයාට ඕනෑම විධානයක් ක්‍රියාත්මක කිරීමට හැකි වීම ගැටළුවක් නොවේද?.. පොදුවේ, ඔබ එය භාවිතා කරන්නේ කෙසේදැයි හරියටම සොයා ගන්නේ නම් මෙම ක්‍රමය බැහැර කළ නොහැක. අපි පසුව මෙම ක්‍රමයට ආපසු යන්නෙමු, නමුත් දැනට අපි වෙනත් විකල්ප කෙටියෙන් සලකා බලමු, සමහර විට සරල දෙයක් තිබිය හැකිය.

  • git දේශීය ප්‍රොටෝකෝලය sshfs සමඟ ඒකාබද්ධව භාවිතා කළ හැකිය, බහු පරිශීලකයින් භාවිතා කළ හැකිය, නමුත් අත්‍යවශ්‍යයෙන්ම පෙර අවස්ථාවට සමාන වේ
  • http - කියවීමට පමණි
  • git කියවීමට පමණි
  • https - ස්ථාපනය කිරීමට අපහසුය, ඔබට අතිරේක මෘදුකාංග, පරිශීලක ප්රවේශය සංවිධානය කිරීම සඳහා යම් ආකාරයක පාලක පැනලයක් අවශ්ය වේ ... එය කළ හැකි බව පෙනේ, නමුත් කෙසේ හෝ සියල්ල සංකීර්ණ වේ.

Git සේවාදායකයට බහු-පරිශීලක ප්‍රවේශය සංවිධානය කිරීමට ssh ප්‍රොටෝකෝලය භාවිතා කිරීම

අපි නැවත ssh ප්‍රොටෝකෝලය වෙත යමු.

ඔබ git සඳහා ssh ප්‍රවේශය භාවිතා කරන බැවින්, ඔබ සේවාදායක දත්තවල ආරක්ෂාව සහතික කළ යුතුය. ssh හරහා සම්බන්ධ වන පරිශීලකයා ලිනක්ස් සේවාදායකයේ තමන්ගේම පිවිසුමක් භාවිතා කරයි, එබැවින් ඔවුන්ට ssh සේවාදායකයා හරහා සම්බන්ධ වී සේවාදායකයේ විධාන රේඛාවට ප්‍රවේශ විය හැකිය.
එවැනි ප්රවේශයට එරෙහිව සම්පූර්ණ ආරක්ෂාවක් නොමැත.

නමුත් පරිශීලකයා ලිනක්ස් ගොනු ගැන උනන්දු නොවිය යුතුය. වැදගත් තොරතුරු git ගබඩාවේ පමණක් ගබඩා කර ඇත. එබැවින්, විධාන රේඛාව හරහා ප්රවේශය සීමා නොකිරීමට හැකි ය, නමුත් Linux මෙවලම් භාවිතා කරමින් පරිශීලකයා සහභාගී වන ව්යාපෘති හැර, ව්යාපෘති බැලීම තහනම් කරයි.
පැහැදිලි තේරීම වන්නේ ලිනක්ස් අවසර පද්ධතිය භාවිතා කිරීමයි.

දැනටමත් සඳහන් කර ඇති පරිදි, ssh ප්රවේශය සඳහා එක් ගිණුමක් පමණක් භාවිතා කළ හැකිය. මෙම වින්‍යාසය නිර්දේශිත git විකල්ප ලැයිස්තුවට ඇතුළත් වුවද, පරිශීලකයින් කිහිප දෙනෙකුට අනාරක්ෂිත ය.

ලිපියේ ආරම්භයේ දක්වා ඇති අවශ්‍යතා ක්‍රියාත්මක කිරීම සඳහා, අයිතිවාසිකම් සහ හිමිකරුවන් පැවරීම සමඟ පහත නාමාවලි ව්‍යුහය නිර්මාණය කර ඇත:

1) ව්යාපෘති නාමාවලි

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
එහිදී
dir1, dir2, dir3 - ව්‍යාපෘති නාමාවලි: ​​ව්‍යාපෘතිය 1, ව්‍යාපෘතිය 2, ව්‍යාපෘතිය 3.

proj1:proj1, proj2:proj2, proj3:proj3 යනු විෙශේෂෙයන් නිර්මාණය කරන ලද ලිනක්ස් භාවිතා කරන්නන් වන අතර ඔවුන් අදාළ ව්‍යාපෘති නාමාවලිවල හිමිකරුවන් ලෙස පවරනු ලැබේ.

සියලුම නාමාවලි සඳහා අවසර 0770 ලෙස සකසා ඇත - හිමිකරුට සහ ඔහුගේ කණ්ඩායමට සම්පූර්ණ ප්‍රවේශය සහ අනෙක් සියල්ලන්ටම සම්පූර්ණ තහනමක්.

2) සංවර්ධක ගිණුම්

Разработчик 1: dev1:dev1,proj1,proj2
Разработчик 2: dev2:dev2,proj2,proj3

ප්රධාන කරුණ වන්නේ සංවර්ධකයින්ට අනුරූප ව්යාපෘතියේ පද්ධති පරිශීලක හිමිකරුගේ අතිරේක කණ්ඩායමක් පවරනු ලැබේ. මෙය Linux server administrator විසින් එක් විධානයකින් සිදු කරයි.

මෙම උදාහරණයේ දී, "සංවර්ධක 1" ව්‍යාපෘති proj1 සහ proj2 මත ක්‍රියා කරයි, සහ "සංවර්ධක 2" ව්‍යාපෘති proj2 සහ proj3 මත වැඩ කරයි.

කිසියම් සංවර්ධකයෙකු විධාන රේඛාව හරහා ssh හරහා සම්බන්ධ වන්නේ නම්, ඔවුන් සහභාගී නොවන ව්‍යාපෘති නාමාවලිවල අන්තර්ගතය බැලීමට පවා ඔවුන්ගේ අයිතිවාසිකම් ප්‍රමාණවත් නොවේ. මෙය ඔහුටම වෙනස් කළ නොහැක.

මෙම මූලධර්මයේ පදනම Linux අයිතිවාසිකම්වල මූලික ආරක්ෂාව වන බැවින්, මෙම යෝජනා ක්රමය විශ්වසනීයයි. මීට අමතරව, යෝජනා ක්රමය පරිපාලනය කිරීම ඉතා පහසුය.

අපි පුහුණුවීම් වලට යමු.

ලිනක්ස් සේවාදායකයක් මත Git ගබඩාවන් නිර්මාණය කිරීම

අපි පරීක්ෂා කරමු.

[root@server ~]# cd /var/
[root@server var]# useradd gitowner
[root@server var]# mkdir gitservertest
[root@server var]# chown gitowner:gitowner gitservertest
[root@server var]# adduser proj1
[root@server var]# adduser proj2
[root@server var]# adduser proj3
[root@server var]# adduser dev1
[root@server var]# adduser dev2
[root@server var]# passwd dev1
[root@server var]# passwd dev2

අතින් ටයිප් කරලා එපා වෙලා...

[root@server gitservertest]# sed "s/ /n/g" <<< "proj1 proj2 proj3" | while read u; do mkdir $u; chown $u:$u $u; chmod 0770 $u; done

[root@server gitservertest]# usermod -aG proj1 dev1
[root@server gitservertest]# usermod -aG proj2 dev1
[root@server gitservertest]# usermod -aG proj2 dev2
[root@server gitservertest]# usermod -aG proj3 dev2

විධාන රේඛාවෙන් වෙනත් පුද්ගලයින්ගේ ගබඩාවලට ප්‍රවේශ වීමට සහ ඒවායේ අන්තර්ගතය බැලීමට පවා නොහැකි බව අපට ඒත්තු ගොස් ඇත.

[dev1@server ~]$ cd /var/gitservertest/proj3
-bash: cd: /var/gitservertest/proj3: Permission denied
[dev1@server ~]$ ls /var/gitservertest/proj3
ls: cannot open directory /var/gitservertest/proj3: Permission denied

Git හි එකම ව්‍යාපෘතියේ බහු සංවර්ධකයින් සමඟ සහයෝගයෙන් කටයුතු කරන්න

එක් ප්‍රශ්නයක් ඉතිරිව ඇත, එක් සංවර්ධකයෙකු නව ගොනුවක් හඳුන්වා දෙන්නේ නම්, වෙනත් සංවර්ධකයින්ට එය වෙනස් කළ නොහැක, මන්ද ඔහුම එහි හිමිකරු (උදාහරණයක් ලෙස, dev1), සහ ව්‍යාපෘතියේ පරිශීලක හිමිකරු නොවේ (උදාහරණයක් ලෙස, proj1). අපිට server-side repository එකක් තියෙන නිසා මුලින්ම අපි දැනගන්න ඕන “.git” ඩිරෙක්ටරිය ව්‍යුහගත වෙන්නේ කොහොමද සහ අලුත් ෆයිල් හදනවද කියලා.

දේශීය Git ගබඩාවක් නිර්මාණය කිරීම සහ Git සේවාදායකය වෙත තල්ලු කිරීම

අපි සේවාදායක යන්ත්‍රය වෙත යමු.

Microsoft Windows [Version 6.1.7601]
(c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены.

C:gittest>git init .
Initialized empty Git repository in C:/gittest/.git/

C:gittest>echo "test dev1 to proj2" > test1.txt

C:gittest>git add .

C:gittest>git status
On branch master
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   test1.txt

C:gittest>git commit -am "new test file added"
[master (root-commit) a7ac614] new test file added
 1 file changed, 1 insertion(+)
 create mode 100644 test1.txt
 
C:gittest>git remote add origin "ssh://[email protected]/var/gitservertest/proj2"

C:gittest>git push origin master
dev1:[email protected]'s password:
Counting objects: 3, done.
Writing objects: 100% (3/3), 243 bytes | 243.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://10.1.1.11/var/gitservertest/proj2
 * [new branch]      master -> master

C:gittest>

ඒ සමගම, සේවාදායකයේ නව ගොනු නිර්මාණය කර ඇති අතර, ඒවා තල්ලු කිරීම සිදු කළ පරිශීලකයාට අයත් වේ

[dev1@server proj2]$ tree
.
├── 1.txt
├── branches
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   └── update.sample
├── info
│   └── exclude
├── objects
│   ├── 75
│   │   └── dcd269e04852ce2f683b9eb41ecd6030c8c841
│   ├── a7
│   │   └── ac6148611e69b9a074f59a80f356e1e0c8be67
│   ├── f0
│   │   └── 82ea1186a491cd063925d0c2c4f1c056e32ac3
│   ├── info
│   └── pack
└── refs
    ├── heads
    │   └── master
    └── tags

12 directories, 18 files
[dev1@server proj2]$ ls -l objects/75/dcd269e04852ce2f683b9eb41ecd6030c8c841
-r--r--r--. 1 dev1 dev1 54 Jun 20 14:34 objects/75/dcd269e04852ce2f683b9eb41ecd6030c8c841
[dev1@server proj2]$

ඔබ Git සේවාදායකයට වෙනස්කම් උඩුගත කරන විට, අතිරේක ගොනු සහ නාමාවලි සාදනු ලබන අතර, ඒවායේ හිමිකරු ඇත්ත වශයෙන්ම උඩුගත කරන පරිශීලකයා වේ. නමුත් පසුව මෙම ගොනු සහ නාමාවලි සමූහය මෙම පරිශීලකයාගේ ප්‍රධාන කණ්ඩායමට අනුරූප වේ, එනම්, dev1 පරිශීලකයා සඳහා dev1 කණ්ඩායම සහ dev2 පරිශීලකයා සඳහා dev2 කණ්ඩායම (සංවර්ධක පරිශීලකයාගේ ප්‍රධාන කණ්ඩායම වෙනස් කිරීම උපකාරී නොවේ, මන්ද එවිට ඔබට බහු ව්‍යාපෘතිවල වැඩ කළ හැක්කේ කෙසේද?). මෙම අවස්ථාවෙහිදී, පරිශීලක dev2 හට පරිශීලක dev1 විසින් සාදන ලද ගොනු වෙනස් කිරීමට නොහැකි වනු ඇත, එය ක්‍රියාකාරීත්වයේ බිඳ වැටීමකට තුඩු දිය හැකිය.

Linux chown - සාමාන්‍ය පරිශීලකයෙකු විසින් ගොනුවක හිමිකරු වෙනස් කිරීම

ගොනුවක හිමිකරුට එහි හිමිකාරිත්වය වෙනස් කළ නොහැක. නමුත් ඔහුට ඔහුට අයත් ගොනුවක කණ්ඩායම වෙනස් කළ හැකි අතර, පසුව එම කණ්ඩායමේ සිටින වෙනත් පරිශීලකයින්ට මෙම ගොනුව වෙනස් කළ හැකිය. අපට අවශ්‍ය වන්නේ එයයි.

Git hook භාවිතා කිරීම

කොක්ක සඳහා වැඩ කරන නාමාවලිය ව්‍යාපෘතියේ මූල නාමාවලියයි. hook යනු තල්ලු කරන පරිශීලකයා යටතේ ධාවනය වන executable එකකි. මෙය දැනගෙන අපට අපගේ සැලසුම් ක්‍රියාත්මක කළ හැකිය.

[dev1@server proj2]$ mv hooks/post-update{.sample,}
[dev1@server proj2]$ sed -i '2,$ s/^/#/' hooks/post-update
[dev1@server proj2]$ cat <<< 'find . -group $(whoami) -exec chgrp proj2 '"'"'{}'"'"' ;' >> hooks/post-update

හෝ හුදෙක් 

vi hooks/post-update

අපි සේවාදායක යන්ත්‍රය වෙත ආපසු යමු.

C:gittest>echo "dev1 3rd line" >> test1.txt

C:gittest>git commit -am "3rd from dev1, testing server hook"
[master b045e22] 3rd from dev1, testing server hook
 1 file changed, 1 insertion(+)

C:gittest>git push origin master
dev1:[email protected]'s password:
   d22c66e..b045e22  master -> master

Git සේවාදායකයේ, අපි කැපවීමෙන් පසු කොක්ක පශ්චාත් යාවත්කාලීන ස්ක්‍රිප්ටයේ ක්‍රියාකාරිත්වය පරීක්ෂා කරමු 

[dev1@server proj2]$ find . ! -group proj2

- හිස්, හැම දෙයක්ම හොඳයි.

Git හි දෙවන සංවර්ධකයෙකු සම්බන්ධ කිරීම

දෙවන සංවර්ධකයාගේ කාර්යය අනුකරණය කරමු.

සේවාදායකයා මත

C:gittest>git remote remove origin

C:gittest>git remote add origin "ssh://[email protected]/var/gitservertest/proj2"

C:gittest>echo "!!! dev2 added this" >> test1.txt

C:gittest>echo "!!! dev2 wrote" > test2.txt

C:gittest>git add test2.txt

C:gittest>git commit -am "dev2 added to test1 and created test2"
[master 55d49a6] dev2 added to test1 and created test2
 2 files changed, 2 insertions(+)
 create mode 100644 test2.txt

C:gittest>git push origin master
[email protected]'s password:
   b045e22..55d49a6  master -> master

ඒ සමඟම, සේවාදායකයේ ...

[dev1@server proj2]$ find . ! -group proj2

- නැවතත් හිස්, සියල්ල ක්රියා කරයි.

Git ව්‍යාපෘතියක් මකා දැමීම සහ Git සේවාදායකයෙන් ව්‍යාපෘතිය බාගත කිරීම

හොඳයි, ඔබට නැවත වරක් සියලු වෙනස්කම් සුරැකී ඇති බවට සහතික විය හැක.

C:gittest>rd /S /Q .
Процесс не может получить доступ к файлу, так как этот файл занят другим процессом.

— Git ව්‍යාපෘතියක් මකා දැමීමට, නාමාවලිය සම්පූර්ණයෙන්ම ඉවත් කරන්න. මෙම විධානය භාවිතයෙන් වත්මන් නාමාවලිය මකා දැමිය නොහැකි බැවින්, ජනනය වන දෝෂය සමඟ අපි ඉවසමු, නමුත් මෙය හරියටම අපට අවශ්‍ය හැසිරීමයි.

C:gittest>dir
 Содержимое папки C:gittest

21.06.2019  08:43    <DIR>          .
21.06.2019  08:43    <DIR>          ..

C:gittest>git clone ssh://[email protected]/var/gitservertest/proj2
Cloning into 'proj2'...
[email protected]'s password:

C:gittest>cd proj2

C:gittestproj2>dir
 Содержимое папки C:gittestproj2

21.06.2019  08:46    <DIR>          .
21.06.2019  08:46    <DIR>          ..
21.06.2019  08:46               114 test1.txt
21.06.2019  08:46                19 test2.txt
C:gittestproj2>type test1.txt
"test dev1 to proj2"
"dev1 added some omre"
"dev1 3rd line"
"!!! dev2 added this"

C:gittestproj2>type test2.txt
"!!! dev2 wrote"

Git හි ප්‍රවේශය බෙදාගැනීම

දැන් අපි Git හරහා පවා දෙවන සංවර්ධකයාට ඔහු වැඩ නොකරන Proj1 ව්‍යාපෘතියට ප්‍රවේශ විය නොහැකි බවට වග බලා ගනිමු.

C:gittestproj2>git remote remove origin

C:gittestproj2>git remote add origin "ssh://[email protected]/var/gitservertest/proj1"

C:gittestproj2>git push origin master
[email protected]'s password:
fatal: '/var/gitservertest/proj1' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

දැන් අපි ප්රවේශය ලබා දෙන්නෙමු

[root@server ~]# usermod -aG proj1 dev2

ඊට පස්සේ හැම දෙයක්ම වැඩ කරනවා.

C:gittestproj2>git push origin master
[email protected]'s password:
To ssh://10.1.1.11/var/gitservertest/proj1
 * [new branch]      master -> master

වැඩි විස්තර සඳහා,

අතිරේකව, ගොනු සහ නාමාවලි නිර්මාණය කිරීමේදී පෙරනිමි අවසරයන් සමඟ ගැටළුවක් තිබේ නම්, CentOS හි ඔබට විධානය භාවිතා කළ හැකිය

setfacl -Rd -m o::5 -m g::7 /var/gitservertest

ලිපියේ ඔබට කුඩා ප්‍රයෝජනවත් දේවල් මත පැකිලීමට ඉඩ ඇත:

  • ලිනක්ස් හි ඩිරෙක්ටරි ගසක් සාදා ගන්නේ කෙසේද
  • යම් රේඛාවක සිට ගොනුවේ අවසානය දක්වා ලිපින පරාසයක් ලබා ගන්නේ කෙසේද, එනම්, පළමු පේළිය හැර අනෙකුත් සියලුම පේළිවල sed හි ප්‍රතිස්ථාපනය කරන්න
  • Linux find හි සෙවුම් කොන්දේසියක් ප්‍රතිලෝම කරන්නේ කෙසේද
  • ලිනක්ස් කවචයේ ඇති එක්-ලයිනර් භාවිතයෙන් ලූපයකට රේඛා කිහිපයක් මාරු කරන්නේ කෙසේද
  • bash හි තනි උද්ධෘත වලින් බේරෙන්නේ කෙසේද
  • වින්ඩෝස් විධාන රේඛාවේ ඇති සියලුම අන්තර්ගතයන් සහිත නාමාවලියක් මකා දැමිය යුතු ආකාරය
  • ගොනුවක් නැවත ලියන්නේ නැතිව rename කිරීමට bash mv භාවිතා කරන්නේ කෙසේද?

ඔබේ අවධානය ඔබට ස්තුතියි.

මූලාශ්රය: www.habr.com

අදහස් එක් කරන්න