4.1 گیت روی سرور - پروتکل‌ها

مزایای مخزن‌های مبتنی بر فایل این است که ساده هستند و اینکه از مجوز‌های فایل موجود و دسترسی شبکه استفاده می‌کنند. اگر شما از قبل یک فایل‌سیستم اشتراک‌گذاری شده دارید که همهٔ تیم به آن دسترسی دارند،‌ راه‌اندازی یک مخزن بسیار آسان است. شما نسخه بِر مخزن را جایی که همه دسترسی اشتراکی به آن را دارند می‌گذارید و مجوزهای خواندن/نوشتن را همانطور که روی هر پوشه اشتراکی دیگری تنظیم می‌کردید، تنظیم می‌کنید. درباره نحوه صادر کردن یک نسخه بر مخزن برای این کار در راه‌اندازی گیت در سرور بحث خواهیم کرد.

همچنین این یک گزینه قشنگ برای برداشتن سریع کار از مخزن کاری شخص دیگری است. اگر شما و همکارتان در حال کار بر روی یک پروژه هستید و او از شما می‌خواهد که چیزی را بررسی کنید، اجرای دستوری مثل git pull /home/john/project اغلب خیلی راحت‌تر از این است که او به یک سرور ریموت پوش کند و متعاقباً شما از آن فچ کنید.

از معایب این متد این است که دسترسی اشتراکی به طور کلی از نظر راه‌اندازی و دسترسی از چندین موقعیت دشوارتر از دسترسی ساده شبکه است. اگر بخواهید از زمانی که خانه هستید از لپتاپتان پوش کنید، باید دیسک ریموت را مونت کنید که می‌تواند در مقایسه با دسترسی برمبنای شبکه سخت و کند‌ باشد.

لازم به ذکر است که اگر در حال استفاده از مونت اشتراک‌گذاری شده خاصی هستید، این لزوماً سریع‌ترین گزینه نیست. یک مخزن محلی تنها زمانی سریع است که دسترسی سریع به داده آن داشته باشید. یک مخزن بر روی NFS گاهاً کندتر از یک مخزن بر روی همان سرور اما به واسطه SSH است، که به گیت اجازه می‌دهد تا اطلاعات را به دیسک‌های محلی هر سیستم منتقل کند.

در نهایت، این پروتکل از مخزن در برابر آسیب‌ تصادفی محافظت نخواهد کرد. هر کابری دسترسی شل کامل به پوشه «ریموت» دارد و هیچ چیز جلوگیری آنها را نمی‌گیرد که فایل‌های داخلی گیت را پاک نکنند یا تغییر ندهند و به مخزن آسیب نزنند.

پروتکل HTTP هوشمند بسیار شبیه به SSH یا پروتکل‌های گیت عمل می‌کند منتهی بر بستر استاندارد درگاه‌های HTTPS اجرا می‌شود و می‌تواند از مکانیزم‌های گوناگون تصدیق هویت HTTP استفاده کند، به این معنا که معمولاً برای کاربر از چیزی مثل SSH راحت‌تر است، چراکه شما می‌توانید از چیز‌هایی مانند نام‌ کاربری/رمز‌عبور برای تصدیق هویت استفاده کنید جای اینکه اجباراً کلید‌های SSH را راه‌اندازی کنید.

احتمالاً در حال حاضر این محبوب‌ترین راه برای استفاده از گیت است، از آنجا که می‌تواند تنظیم شود تا هم به طور ناشناس خدمت کند، مانند پروتکل git:// و همچنین می‌تواند تنظیم شود تا همراه تصدیق هویت و رمزگذاری مانند پروتکل SSH کار کند. به جای اینکه مجبور باشید چندین URL متفاوت برای چنین چیز‌هایی راه‌اندازی کنید، حال می‌توانید از یک URL برای هر دو استفاده کنید. اگر سعی در پوش کردن به مخزن دارید و تصدیق هویت ضروری باشد (که معمولاً هست)، سرور می‌تواند از شما نام کاربری و رمزعبور درخواست کند. همین روند نیز برای دسترسی خواندن وجود دارد.

در واقع، برای سرویس‌های مانند گیت‌هاب، URL که شما برای نمایش آنلاین مخزن خود استفاده می‌کنید (برای مثال، https://github.com/schacon/simplegit) همان URL است که می‌توانید برای کلون کردن، و در صورت داشتن دسترسی، پوش کردن استفاده کنید.

اگر سرور با پروتکل HTTP هوشمند پاسخ ندهد،‌ کلاینت گیت تلاش می‌کند تا به پروتکل ساده‌تر HTTP غیرهوشمند (Dumb) بازگردد. پروتکل غیرهوشمند انتظار دارد که مخزن بِر گیت مانند فایل‌های معمولی از طرف وب سرور میزبانی شود. قشنگی HTTP غیرهوشمند سادگی راه‌اندازی آن است. در اصل، تمام کاری که شما باید انجام دهید این است که مخزن بِر گیت را زیر HTTP داکیومنت-روت قرار دهید و قلاب مشخصی برای post-update («بعد از بروزرسانی») راه‌اندازی کنید و تمام‌ (به Git Hooks مراجعه کنید).

همهٔ کار همین است. قلاب post-update که همراه گیت می‌آید به طور پیش فرض دستورات مناسب را اجرا می‌کند (git update-server-info) تا فچ و کلون HTTP به درستی کار کنند. این دستور زمانی اجرا می‌شود که شما به این مخزن پوش کنید‌ (احتمالاً بر بستر SSH)؛ سپس دیگر افراد می‌توانند توسط چنین چیزی کلون کنند

در این مورد خاص، ما از مسیر /var/www/htodcs استفاده می‌کنیم که مرسوم سیستم‌های آپاچی است، اما شما می‌تواند از هر وب سرور ایستای دیگری استفاده کنید — کافیست مخزن بِر را در مسیر آن قرار دهید. داده‌های گیت به عنوان فایل‌های ایستای معمولی میزبانی می‌شوند (برای جزئیات دقیق نحوهٔ‌ میزبانی شدن به Git Internals مراجعه کنید).

عموماً یا مجبور خواهید شد که یک سرور خواندنی/نوشتنی هوشمند HTTP راه‌اندازی کنید یا صرفاً فایل‌ها را با دسترسی فقط-خواندنی به روش غیرهوشمند فراهم کنید. استفاده از ترکیب این دو سرویس نادر است.

ما تمرکزمان را بر روی مزایای نسخه هوشمند پروتکل HTTP خواهیم گذاشت.

سادگی داشتن فقط یک URL برای انواع دسترسی‌ها و داشتن اعلان سرور فقط در زمانی نیاز به که تصدیق هویت، همه چیز را برای کاربر نهایی بسیار ساده می‌کند. قابلیت تصدیق هویت با نام کاربری و رمزعبور بر بستر SSH یک مزیت بزرگ است، چرا که کاربران نیاز به ساخت محلی کلیدهای SSH به صورت محلی و آپلود کلید عمومی خود به روی سرور پیش از اجازه گرفتن برای برقراری تعامل با آن ندارند. برای کاربرانی که در سطح پایین‌تری هستند یا کاربران سیستم‌هایی که SSH روی آن‌ها کمتر متداول است، این مزیت اصلی در استفاده‌پذیری است. همچنین پروتکلی بسیار سریع و کارآمد همانند پروتکل SSH است.

همچنین می‌توانید مخزن‌های فقط-خواندنی خود را بر بستر HTTPS نیز میزبانی کنید که به این معنا است که شما می‌توانید انتقال محتوا را رمزگذاری کنید؛ یا می‌توانید اجبار کلاینت‌ها به استفاده از یک گواهی SSL امضا شده خاص پیش روید.

نکته قشنگ دیگر این است که هر دو پروتکل HTTP و HTTPS پروتکل‌هایی آنچنان پر استفاده هستند که فایروال‌های شرکتی اغلب به نحوی راه‌اندازی می‌شوند تا اجازه عبور و مرور از طریق پروتکل‌ها را مجاز بدانند.

ممکن است بر روی بعضی از سرور‌ها، راه‌اندازی گیت بر بستر HTTPS به مهارت بیشتری در مقایسه با SSH احتیاج داشته باشد. سوای این مورد، مزیت‌های خیلی کمی در دیگر پروتکل‌ها در مقایسه با HTTP هوشمند برای میزبانی محتوای گیت است.

اگر از HTTP برای پوش احراز هویت شده استفاده می‌کنید، تهیه گواهی‌هایتان گاهی اوقات پیچیده‌تر از استفاده از کلید‌ها بر بستر SSH است. با این حال چندین ابزار ذخیره‌ساز گواهی وجود دارد که می‌توانید استفاده کنید که شامل «Keychain access» در سیستم‌عامل مک و «Credential Manager»‌ در ویندوز است که این مشکل را آسان‌تر کند. بخش Credential Storage را مطالعه کنید تا چگونگی راه‌اندازی ذخیره‌سازی امن رمزعبور بر بستر HTTP بر روی سیستم خودتان را بدانید.

مزایای استفاده از پروتکل SSH بسیار زیاد است. اول، SSH نسبتاً راه‌اندازی ساده‌ای دارد — دیمن‌های SSH پیش افتاده هستند،‌ خیلی از مدیریان شبکه تجربه کار با آنها را دارند و خیلی از توزیع‌های سیستم‌عامل‌ها همراه آنها راه‌اندازی می‌شوند یا ابزارهایی برای مدیریت آنها دارند. سپس اینکه، دسترسی بر بستر SSH امن است — کل انتقال داده‌ها رمزگذاری شده و تصدیق هویت شده است. در آخر، مانند HTTPS، گیت و پروتکل‌های محلی، SSH نیز کارآمد است، قبل از ارسال اطلاعات تا جایی که ممکن است داده‌ها را فشرده می‌کند.

وجه منفی پروتکل SSH این است که از دسترسی ناشناس به مخزن گیت شما پشتیبانی نمی‌کند. اگر از SSH استفاده می‌کنید، افراد باید دسترسی SSH به سیستم شما داشته باشند، حتی در حد فقط-خواندن؛ این باعث می‌شود که SSH برای پروژه‌های متن باز که شاید افراد بخواهند صرفاً مخزن شما را کلون کرده و آن را بررسی کنند مناسب نباشد. اگر از SSH فقط در شبکه شرکتی استفاده می‌کنید، شاید SSH تنها پروتکلی باشد که لازم باشد با آن سروکار داشته باشد. اگر می‌خواهید دسترسی ناشناس فقط-خواندن به پروژه‌های خود بدهید و همچنان از SSH هم استفاده کنید، ملزم خواهید بود که SSH را برای پوش کردن خودتان، اما برای دیگران چیز دیگری راه‌اندازی کنید تا از آن فچ کنند.

پروتکل گیت اغلب سریعترین پروتکل موجود شبکه است. اگر حجم عظیمی از ترافیک را برای یک پروژه عمومی یا بزرگ که نیاز به تصدیق هویت کاربر برای دسترسی خواندن ندارد را میزبانی می‌کنید، احتمالاً که خواهید خواست که یک دیمون گیت را برای میزبانی پروژتان راه‌اندازی کنید. این از همان مکانیزم انتقال-اطلاعاتی که پروتکل SSH دارد استفاده می‌کند اما بدون رمزگذاری و تصدیق هویت.

نقطه ضعف پروتکل گیت نداشتن تصدیق هویت است. اصلاً مطلوب نیست که پروتکل گیت تنها راه دسترسی به پروژه شما باشد. عموماً، برای تعدادی از توسعه‌ دهندگان یا برنامه‌نویسان که دسترسی پوش (نوشتن) دارند آن را با پروتکل SSH یا HTTPS همراه خواهید کرد و برای بقیه با دسترسی فقط خواندنی از git://، استفاده خواهید کرد. احتمالاً سخت‌ترین پروتکل‌ها برای راه‌اندازی است. باید روی دیمون خودش اجرا شود که نیازمند پیکربندی systemd و xinetd یا چیزی مشابه است که می‌توان گفت همیشه به آسانی آب خوردن نیست. همچنین نیازمند دسترسی فایروال به پورت ۹۴۱۸ است که چون یک پورت استاندارد نیست شاید فایر‌وال‌های شرکتی همیشه اجازه آنرا ندهند. پشت فایروال‌های بزرگ شرکتی غالباً پورت‌های ناامن این چنینی را مسدود هستند.