Schlagwort-Archive: tools

Lokale PHP-Entwicklungsumgebung mit Laravel Valet

Valet ist eine Umgebung, die PHP-Projekte aus einem lokalen Verzeichnis automatisch im Browser verfügbar macht. Es ist eine leichtgewichtige Alternative zu Vagrant oder Docker. Um es gleich vorweg zu nehmen: Die hier vorgestellte Lösung ist nicht an Laravel gebunden sondern eignet sich für die Entwicklung von PHP-Projekten aller Art (z.B. Symfony, Zend, Drupal, WordPress, Magento, usw.).

Valet funktioniert knapp gesagt so: Man gibt in einem Ordner in dem Projekte liegen valet park ein. Ab da kann man die Projekte in dem Ordner über verzeichnis.dev im Browser aufrufen. Gibt man noch valet secure verzeichnis ein, kann man die Seite sogar über https://verzeichnis.dev aufrufen (ohne Zertifikats-Fehler).

Verbindung mit ngrok beobachten

Will man jemandem von Extern Zugriff auf die lokale Entwicklungsumgebung gewähren ist dies mit valet share möglich. Diese Funktion nutzt ngrok, um einen Tunnel aufzubauen und generiert einen Link, den man teilen kann. In einem lokalen Webinterface kann man noch jeden externen Request beobachten und inspizieren.

Bevor wir zur Einrichtung kommen, hier noch mal schnell ein lustiges Fake-Marketing-Video zu Valet:

Installation

Ab Ubuntu 17.04 funktioniert Valet „dank“ systemd leider nicht mehr out-of-the-box. Wie man die Probleme behebt habe ich im vorheringen Artikel beschrieben (Update: Im aktuellen Valet funktioniert es auch ohne eigene Änderungen an 17.04). Im Folgenden gehe ich davon aus, dass composer bereits installiert ist und $HOME/.composer/vendor/bin im Pfad liegt. Wir benutzen nicht die offizielle Version von Valet, sondern einen Fork, der auch unter Linux funktioniert (neben Ubuntu sind auch Fedora und Arch getestet).

sudo apt install libnss3-tools jq xsel php7.0-cli php7.0-curl php7.0-mbstring php7.0-mcrypt php7.0-xml php7.0-zip php7.0-sqlite3 php7.0-mysql
composer global require cpriego/valet-linux
valet install
mkdir ~/Sites
cd ~/Sites && valet park

Alle Projekte, die nun in ~/Sites liegen, sind über verzeichnis.dev aufrufbar. Über Treiber erkennt Valet, um was für eine Art von Projekt es sich handelt und serviert es entsprechend dem Browser. Auf Github gibt es eine Liste der Treiber, man kann aber auch leicht eigene schreiben.

Viel Spaß beim Coden. ;-)

1 Antwort

Gitea oder Gogs statt Github und Gitlab

Update 01/2018: Gogs ist mal wieder seit mehreren Montaten tot bzw. der alleinige Entwickler nicht erreichbar. Ich kann nur ausdrücklich dazu raten auf den Fork Gitea zu setzen.

Ich habe mir den Github-Klon Gogs und dessen Fork Gitea näher angeschaut und bin hellauf begeistert. Weiter unten erkläre ich noch, wie ich Gogs bzw. Gitea TLS-verschlüsselt hinter Nginx laufen lasse. Nun aber erst mal zu Gogs und warum ich es brauche.

Github ist über die Jahre zum defacto-Standard für Opensource-Entwicklung geworden. Das liegt zum einen an den Features, die Github bietet (Pull-Requests, Issues, Wiki). Die Popularität rührt aber auch daher, dass diese Features sehr einfach gehalten sind. Das Issue-Tracking ist extrem rudimentär, alles andere ist aber für viele Overkill. Github hat das Mitmachen einfach gemacht.

Es gibt allerdings auch Gründe, die gegen die Nutzung von Github sprechen. Github selbst ist z.B. keine Opensource Software. Möchte man auch private Repositories erstellen, braucht man ein kostenpflichtiges Konto. Das habe ich zwar, aber trotzdem möchte ich nicht zwangsläufig das Schicksal meines Codes einer Firma überlassen, über die ich keine Kontrolle habe. Dank der Dezentralität von Git schadet es auch nicht mehrgleisig zu fahren (z.B. Mirror auf Github für Pull-Requests und issues).

Die erste Alternative, die ich mir angeschaut habe, war Gitlab. Komplett open source, ähnliche Features wie Github und dazu noch eine integrierte Plattform für Continuous Integration. Nach einem halben Tag Installation und Konfiguration (alles eher komplex) hat sich gezeigt, dass meine Hardware nicht leistungsstark genug ist und ich einen extra Server für Gitlab bräuchte. Wo Web, Mail, Seafile (mit ~100 aktiven Usern), Minecraft und diverse andere Dinge klaglos parallel laufen, läuft Gitlab nicht mal allein flüssig. Wie das auf einem Raspberry Pi laufen soll ist mir schleierhaft.

Der nächste Kandidat war dann schon Gogs und es konnte sofort überzeugen. Auf den ersten Blick bietet Gogs die gleichen Features wie Github. Zum Teil nicht ganz so poliert, manchmal wirkt es aber auch schicker. Gogs ist in Go geschrieben (Gogs = Go Git Service) und so leichtgewichtig (~20MB RAM), dass es sogar auf einem Raspberry Pi ordentlich läuft.

Und Gitea?

Gogs wurde vor kurzem geforkt. Nachdem der zentrale Entwickler wiederholt für Monate nicht erreichbar war hatte die Community genug und hat Gitea erstellt. Die Entwicklung beim Fork läuft schneller und transparenter, als es bei Gogs je der Fall war. Meine Empfehlung lautet also, Gitea statt Gogs einzusetzen. An Features muss man im Vergleich zu Git kaum Abstriche machen. Hier mal eine kleine unvollständige Aufstellung:

  • interner Issue Tracker (extern möglich)
  • internes Wiki (ebenso extern möglich)
  • protected branches
  • Git hooks
  • webhooks
  • deploy keys
  • signierte Commits
  • Authentifizierung auch über LDAP, SMTP, OAuth2, OpenID und PAM
  • 2FA
  • Support für DroneCI und andere

Sieht erst mal aus wie Github… funktioniert auch so.
Issues als Projektmanagement. Anbindung an Kanboard geht auch.

Weiterlesen →

21 Antworten