26 czerwca 2016

Hosting GIT dla freelancera

Moje doświadczenia z CodeCommit, czyli hostingiem GIT w ramach oferty firmy Amazon.

Hosting git – Wymagania

Każdy z nas oczekuje czegoś innego od repozytorium GIT. Ja poniżej zebrałem swoje wymagania:

  • Nieograniczona ilość repozytoriów,
  • Prywatność projektów,
  • Korzystną cenę za 1GB / miesiąc,
  • Możliwość dokładnego zdefiniowania, jakie uprawnienia ma user – gdzie ma prawa tylko do odczytu, a gdzie może comitować,
  • Możliwość połączenia GITA z Gerritem,
  • Rozsądna cena – rozumiem przez to, że 5$ miesięcznie jest w porządku. Cenę 10$ mógłbym rozważyć, ale 100$ to już przesada,
  • Szybkość działania – serwer w USA jest akceptowalny, choć wolałbym coś bliżej.

Moje doświadczenia z XP-Dev.com (opens new window)

Przez długi czas korzystałem z usług XP-Dev.com (opens new window), i wydaje mi się ona ciekawą ofertą. Nieograniczona ilość projektów, do każdego projektu system zarządzania bugami (Track (opens new window)). Wszystko działało prawidłowo i dopóki nie znalazłem alternatywy, to płaciłem im zgodnie z cennikiem:

  • Pro Small, 2Gb – $5/miesiąc
  • Pro MSmall, 5Gb – $10/miesiąc
  • Pro Medium, 10Gb – $15/miesiąc
  • Pro Large, 20Gb – $30/miesiąc

Przesiadka na AWS CodeCommit (opens new window)

Pierwotny hosting działał prawidłowo i byłem szczęśliwy aż do momentu, gdy zobaczyłem, że mogę mieć prawie to samo w zamian za kilkanaście dolarów miesięcznie mniej. I kilka dni później korzystałem już z Amazon CodeCommit. Poniżej moja subiektywna lista wad i zalet CodeCommit.

Zalety

  • Dobrze zintegrowany z pozostałymi usługami w ramach AWS.
  • Brak limitu ilości repozytoriów.
  • Pierwszych pięciu użytkowników gratis – potem 1$ miesięcznie za użytkownika.
  • 50 GB miesięcznie gratis.
  • Możliwość automatyzacji zadań, np. po udanym ‘push’ automatycznie kopiujemy repo na S3. O tym niedługo będzie osobny wpis.

Wady

  • Brak możliwości zrobienia publicznego repozytorium.
  • Brak wbudowanych systemów zarządzania bugami.
  • Dla osób niekorzystających z infrastruktury AWS, pierwsza konfiguracja może wydawać się skomplikowana.
  • Usługa dostępna tylko w lokalizacji US East (N. Virginia).
  • Słaby repo explorer w consoli AWS.

Jestem bardzo zadowolony z CodeCommit, łącznie mam ok. 30 repozytoriów i poniżej 50GB danych, zatem jak do tej pory rachunek za omawianą usługę wyniósł mnie $0.

codecommit logo

Konfiguracja repozytorium GIT na AWS

Naszym zadaniem jest utworzenie repozytorium, dodanie nowego usera, oraz nadanie mu odpowiednich uprawnień. Zaczynamy od ekranu głównego webowej consoli administracyjnej AWS.

aws lista
  1. Następnie wybieramy CodeCommit > Create new repository, gdzie podajemy nazwę i opis tworzonego repozytorium.
codecommin nowe repozytorium
  1. Repozytorium utworzone. Teraz musimy stworzyć użytkownika. Będąc na ekranie głównym, przechodzimy do panelu usługi Identity and Access Management > Users
codecommin lista repozytoriów
  1. Klikamy Create New Users oraz określamy nazwę nowo tworzonego użytkownika, następnie powinniśmy zobaczyć poniższy panel.
aws user ustawienia
  1. Chcemy teraz określić, do czego uprawniony jest nowy użytkownik. Nadajemy mu uprawnienie korzystania z klucza SSH. Wchodzimy w Attach Policy i wyszukujemy uprawnienie IAMUserSSHKeys.
aws IAMUserSSHKeys
  1. Kolejnym krokiem jest nadanie uprawnień do repozytorium. Jeśli chcemy, aby użytkownik miał pełne prawo do wszystkich repo, to wystarczy w poprzednim kroku dodać Policy o nazwie AWSCodeCommitFullAccess. Jeśli chcemy bardziej precyzyjnie określić przywileje użytkownika, wówczas musimy utworzyć swoją własną politykę praw dostępu. Z ekranu głównego praw użytkownika wybieramy Create User Policy.
aws set permission
  1. Teraz możemy określić uprawnienia, jakie przydzielamy, np.
  • Jeśli chcemy dać pełne prawa do wszystkich repozytoriów:
{
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "codecommit:*"
          ],
          "Resource": "*"
        }
      ]
    }
  • Jeśli dajemy prawa tylko do odczytu dla dwóch wybranych repozytoriów:
{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "Stmt1456442288000",
                "Effect": "Allow",
                "Action": [
                    "codecommit:GitPull"
                ],
                "Resource": [
                    "arn:aws:codecommit:us-east-1:676716855685:NAZWA1",
                    "arn:aws:codecommit:us-east-1:676716855685:NAZWA2"
                ]
            }
        ]
    }
  • Możemy też ograniczyć prawo do kasowania repozytorium, tak aby zminimalizować ryzyko przypadkowego usunięcia danych:
{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "Stmt1453591829000",
                "Effect": "Deny",
                "Action": [
                    "codecommit:CreateRepository",
                    "codecommit:DeleteRepository"
                ],
                "Resource": [
                    "arn:aws:codecommit:*"
                ]
            }
        ]
    }
  1. Nadaliśmy prawa, pora zdefiniować sposób autoryzacji. Chcemy, aby ten użytkownik autoryzował się tylko przy pomocy klucza SSH, więc dodajemy klucz i usuwamy domyślnie utworzone aws credentials.
aws

Utworzyliśmy użytkownika i repozytorium oraz nadaliśmy mu stosowne uprawnienia. Teraz pora uzyskać dostęp zdalny do repozytorium.

Dostęp do utworzonego repozytorium

Aby dostać się do repo potrzebujemy URL oraz nazwy użytkownika. Nazwa użytkownika to ID naszego klucza SSH. Możemy połączyć je razem i ten adres wykorzystać do połączenia. Oczywiście pamiętając o podpięciu właściwego klucza prywatnego.

ssh://KEY_ID@git-codecommit.us-east-1.amazonaws.com/v1/repos/NAZWA_REPO

aws
aws
aws

Odnośniki