Zum Inhalt springen

_n4p_

Mitglieder
  • Gesamte Inhalte

    1.324
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    14

Reputationsaktivitäten

  1. Like
    _n4p_ erhielt eine Reaktion von thereisnospace für ein Blogeintrag, DIY NAS   
    Vorher
    Der Plan mal wieder ein NAS zu bauen schwirrt schon seit längerem durch meinen Kopf. Alles auf dem PC zu lagern um das Dokument dann doch vom Laptop aus zu bearbeiten oder den Film dann über die PS4 zu sehen ergibt halt auch nur begrenzt Sinn. Also dann dochmal den alten Shuttle-Barebone aus der Schrott-Ecke auf Arbeit mit nach hause genommen, ne alte Grafikkarte und etwas RAM aus der Wühlkiste genommen und zusammengebaut. Positiv: Das Gerät schaltet ein und läuft offenbar auch. Negativ: Es produziert kein Bild, zumindest nicht an meinem Monitor. Was an allem Möglichen liegen könnte. Die Grafikkarte könnte selbst kaputt sein, der DVI auf DP Adapter funktioniert nicht in der benötigten Richtung. Einen anderen Monitor oder eine weitere Grafikkarte zum testen ist aber nicht vorhanden. Ende der Geschichte, bauen wir also kein NAS.
    Planänderung
    Doch. Sonst wäre das hier ja albern. Ne Grafikkarte kaufen um festzustellen das es was anderes ist, wäre auch quatsch. Aber vor einigen Wochen durch Zufall gesehen das jemand ein NAS aus nem RaspberryPi 4 gebaut hat. Die Idee an sich ist ja nix spektakulär Neues. Neu für mich war der 4xSATA-Hat. 

    Es gibt sogar ein Bündel aus SATA-Hat und einem Gehäuse, in dem neben Raspi und Hat auch noch 4 2,5 Zoll SATA-Platten Platz finden. Da ich aber nur einige 3,5 Zoll HDDs übrig habe, war das Gehäuse keine Option. Im weiteren Verlauf der Suche bin ich dann auf den NanoPi M4 gestoßen, bzw. zuerst auf den SATA-Hat für diesen.

    Der NanoPi wird von einem RK3399 angetrieben, daher kann das Board sogar PCIe. Während der Raspi-Hat 2 USB Kanäle nutzt, nutzt der NanoPi-Hat also PCIe. Außerdem ist der RK3399 doch schneller als der RaspberryPi 4. Dafür ist der NanoPi M4v2 auch etwas teurer. Mit Kühlkörper, SATA-Hat und eMMC Karte kostet der Spaß etwa 120 € inkl. Versand. Da kommt dann wohl auch noch etwa 25 € Einfuhrumsatzsteuer drauf. Für nur 20 € mehr hätte man das auch gleich bei Antratek bestellen können. Aber den Shop hab ich erst später gefunden. Das gesamte Konstrukt könnte dann so aussehen.

    Der SATA-Hat versorgt auch gleich den NanoPi mit Strom. Mit dem Molex-Anschluss auf dem Hat kann man auch die Festplatten mit Strom versorgen. Um 4 Festplatten zu betreiben sollte man den Hat aber mit ATX-Netzteil betreiben, dazu kann man den 4-poligen Anschluss auf dem Board nutzen.
    Ein passendes Gehäuse
    Nach einigen verworfenen Ideen - selbst defekte QNAPs gehen auf ebay für jenseits der 150 € Marke weg - werde ich das alte Barbone von Shuttle ein wenig umbauen. Dazu habe ich zunächst einen Festplattenkäfig für 5 3,5 Zoll Platten bestellt. Da ich das Original-Netzteil aus dem Barbone weiter nutzen werde, kann ich nur 4 Platten einbauen, aber mehr wollte ich sowieso nicht. Außerdem möchte ich versuchen den CPU-Kühler des Gehäuses zu nutzen. Damit ist allerdings die oben gezeigte Konfiguration unmöglich, da die CPU des NanoPi auf der Unterseite verbaut ist. Ich muss also den NanoPi umdrehen und den SATA-Hat dann also irgendwie neben dem NanoPi einbauen. Dafür benötigt man aber nur ein paar Kabel und anderen Kleinkram. 

    Und zu guter Letzt möchte man das Gerät auch einschalten können. Da ich ein ATX-Netzteil benutze, könnte man einfach am Mainboard-Stecker - der ja nicht genutzt wird - Pin 16 und 18 Überbrücken. Da das Netzteil dann daerhaft läuft, ist das nicht die beste Lösung. Es gibt sogar schon fertige Schalter für diesen Einsatzzweck. Die schönste Variante die ich gefunden habe. 

    Wartezeit verkürzen
    Da einige Teile eine Lieferzeit von 2-4 Wochen haben. Kann ich mich in der Zwischenzeit ein wenig um die Software und den Umbau des Barebone-Gehäuses kümmern. Zum Umbau wird es in einem nächsten Teil ein paar Bilder geben, aber viel zu sagen gibt es da nicht. Die Software könnte aber noch spannend werden. Es gibt zwar diverse fertige Images für den NanoPi, aber die mag ich nicht. Es gibt allerdings auch ein paar Images aus dem Arch Linux ARM-Projekt für den RK3399. Der erste Schritt wäre nun diese erstmal unter QEMU zu testen und Software nachzuinstallieren bzw runter zu werfen. Der NanoPi hat zwar auch einen SD-Slot von dem er booten kann, das Ziel ist aber die eMMC Karte für das Betriebssystem zu nutzen. Dazu bietet FriendlyArm zwar ein Tool an das ein Linux-Image von der SD-Karte auf die eMMC schreibt. Allerdings muss man dafür sein eigenes Linux in ein Image mit diesem Tool verpacken. Die Anleitung für interessierte gibt es hier: http://wiki.friendlyarm.com/wiki/index.php/EFlasher#Make_Your_Own_eFlasher
  2. Like
    _n4p_ erhielt eine Reaktion von Listener für ein Blogeintrag, Abenteuer mit Linux   
    Hinweise
    Dies wird keine Anleitung für Linuxanfänger. Es wird keine Patentrezepte zum Lösen von Problemen geben. In so gut wie jedem beschriebenem Fall wird es alternative Lösungen geben. An einigen Stellen wird etwas Vorwissen vorausgesetzt.
    Motivation
    Als begeisterter Windowsnutzer seit ca 15 Jahren mit etwas Langeweile, habe ich beschlossen mal etwas verrücktes zu versuchen. Die winzige 256 GB SSD meines Yoga 3 Pro war mal wieder übervoll, also wurde endlich mal eine neue gekauft auf die das Windows umziehen sollte. Was lag also näher als der kleinen SSD auf ihre alten Tage noch etwas Spaß zu gönnen. Nebenbei könnte ich auf die Art die Linuxkentnisse etwas vertiefen und sehen wie viel Spaß Linux auf dem Desktop beziehungsweise Laptop macht. Zum Einen ist dies nicht der erste Ausflug in die Linuxwelt. Erste Versuche wurden zu Zeiten von Debian 2/3 unternommen. Anfangs noch mit SuSE und Red Hat um dann recht schnell bei Debian zu landen und einige Jahre dabei zu bleiben. Zum Anderen habe ich auch beruflich ein paar Linuxserver, mit unterschiedlichen Distributionen, zu verwalten.
    Fragen vor dem Anfang
    Die wichtigste oder unwichtigste Frage am Anfang ist welche Distribution es werden soll. Schaut man bei Distrowatch vorbei versinkt man schnell in einer Unmenge an Varianten. Unter Hauptdistributionen findet man eine Liste der populärsten Distributionen mit einer groben Unterteilung nach Komplexität. Da schon etwas Erfahrung mit Linux vorhanden ist und ich auch nichts komplett vorgekautes benutzen wollte, hab ich mich für Arch Linux entschieden. Einige Server auf Arbeit laufen auch schon damit. Es ist also kein vollkommenes Neuland.
    Die Installation
    Zur Installation gibt es nicht viel zu sagen. Es gibt im Arch-Wiki eine ausführliche Anleitung, der man problemlos folgen kann sofern man lesen und tippen kann. Ein kleiner Stolperstein liegt in der Partitionierung. Früher hab ich beispielsweise /usr auf eine eigene Partition ausgelagert. Unter Arch funktioniert das nicht, da /bin und /sbin nur Symlinks auf /usr/bin und /lib sowie /lib64 Links auf /usr/lib sind. Danach fangen dann die Probleme an.
    Das erste mal booten
    Was zuerst auffällt ist die winzige Schrift in der Konsole, immerhin hat das Yoga 3 Pro ein QHD+ Display bei gerade mal 13 Zoll Diagonale. Zum Glück hatten schon viele ähnliche Probleme und es gibt auch dazu einen Artikel im Arch Wiki.
    Danach möchte man eventuell noch etwas mehr Software installieren. Das wird aber erstmal nichts. Aus Gründen wird der "falsche" Treiber für das WLan-Modul geladen. Der falsche Treiber landet also auf der Blacklist. Ohne WLan wird es allerdings schwierig den richtigen Treiber zu bekommen. Eine Lösung dafür ist einfach nochmal das Installationsmedium zu booten und in das installierte System zu "chrooten". Im Installationssystem ist auch der richtige Treiber verfügbar und kann in das Zielsystem installiert werden. Ist das alles geschafft, darf man dann noch etwas lernen. Es gibt noch "rfkill", mit dem man Bluetooth und WLan ein- beziehungsweise ausschalten kann/darf/muss. Nun kann man das WLan mit "wifi-menu" oder "wpa_supplicant" konfigurieren und weitere Software installieren.
  3. Like
    _n4p_ erhielt eine Reaktion von KeeperOfCoffee für ein Blogeintrag, Abenteuer mit Linux   
    Hinweise
    Dies wird keine Anleitung für Linuxanfänger. Es wird keine Patentrezepte zum Lösen von Problemen geben. In so gut wie jedem beschriebenem Fall wird es alternative Lösungen geben. An einigen Stellen wird etwas Vorwissen vorausgesetzt.
    Motivation
    Als begeisterter Windowsnutzer seit ca 15 Jahren mit etwas Langeweile, habe ich beschlossen mal etwas verrücktes zu versuchen. Die winzige 256 GB SSD meines Yoga 3 Pro war mal wieder übervoll, also wurde endlich mal eine neue gekauft auf die das Windows umziehen sollte. Was lag also näher als der kleinen SSD auf ihre alten Tage noch etwas Spaß zu gönnen. Nebenbei könnte ich auf die Art die Linuxkentnisse etwas vertiefen und sehen wie viel Spaß Linux auf dem Desktop beziehungsweise Laptop macht. Zum Einen ist dies nicht der erste Ausflug in die Linuxwelt. Erste Versuche wurden zu Zeiten von Debian 2/3 unternommen. Anfangs noch mit SuSE und Red Hat um dann recht schnell bei Debian zu landen und einige Jahre dabei zu bleiben. Zum Anderen habe ich auch beruflich ein paar Linuxserver, mit unterschiedlichen Distributionen, zu verwalten.
    Fragen vor dem Anfang
    Die wichtigste oder unwichtigste Frage am Anfang ist welche Distribution es werden soll. Schaut man bei Distrowatch vorbei versinkt man schnell in einer Unmenge an Varianten. Unter Hauptdistributionen findet man eine Liste der populärsten Distributionen mit einer groben Unterteilung nach Komplexität. Da schon etwas Erfahrung mit Linux vorhanden ist und ich auch nichts komplett vorgekautes benutzen wollte, hab ich mich für Arch Linux entschieden. Einige Server auf Arbeit laufen auch schon damit. Es ist also kein vollkommenes Neuland.
    Die Installation
    Zur Installation gibt es nicht viel zu sagen. Es gibt im Arch-Wiki eine ausführliche Anleitung, der man problemlos folgen kann sofern man lesen und tippen kann. Ein kleiner Stolperstein liegt in der Partitionierung. Früher hab ich beispielsweise /usr auf eine eigene Partition ausgelagert. Unter Arch funktioniert das nicht, da /bin und /sbin nur Symlinks auf /usr/bin und /lib sowie /lib64 Links auf /usr/lib sind. Danach fangen dann die Probleme an.
    Das erste mal booten
    Was zuerst auffällt ist die winzige Schrift in der Konsole, immerhin hat das Yoga 3 Pro ein QHD+ Display bei gerade mal 13 Zoll Diagonale. Zum Glück hatten schon viele ähnliche Probleme und es gibt auch dazu einen Artikel im Arch Wiki.
    Danach möchte man eventuell noch etwas mehr Software installieren. Das wird aber erstmal nichts. Aus Gründen wird der "falsche" Treiber für das WLan-Modul geladen. Der falsche Treiber landet also auf der Blacklist. Ohne WLan wird es allerdings schwierig den richtigen Treiber zu bekommen. Eine Lösung dafür ist einfach nochmal das Installationsmedium zu booten und in das installierte System zu "chrooten". Im Installationssystem ist auch der richtige Treiber verfügbar und kann in das Zielsystem installiert werden. Ist das alles geschafft, darf man dann noch etwas lernen. Es gibt noch "rfkill", mit dem man Bluetooth und WLan ein- beziehungsweise ausschalten kann/darf/muss. Nun kann man das WLan mit "wifi-menu" oder "wpa_supplicant" konfigurieren und weitere Software installieren.
  4. Like
    _n4p_ erhielt eine Reaktion von KleinHippo für ein Blogeintrag, Windows Server Container und Docker I   
    Einleitung
    Die grundlegende Frage gleich vornweg: Warum sollte man Docker auf einem Windows Server betreiben?
    Nunja, weil man es kann. Außerdem besteht die Infrastruktur bei den meisten unserer Kunden aus MS SQL-Server und Windows Servern auf denen unsere Software installiert wird. Hier könnte man nun argumentieren, dass unsere Software "nur" PHP und Apache benötigt und das zusammen mit PostGreSQL oder ORACLE durchaus auf Linux laufen könnte. Ja, ist richtig, wir möchten aber nicht auch noch irgendwelche Linux Installationen bei unseren Kunden pflegen.
    Sucht man, naiv wie man ist, einfach mal nach "docker windows", landet man früher oder später bei "Docker CE for Window". Hat man das installiert und den ersten Container gestartet, wird einem auffallen das die Container nicht beim Booten starten. Da ist auch nichts falsch konfiguriert, das soll so sein. Dafür gibt es sicherlich Gründe. Diese Version ist für Entwickler gedacht, die Docker auf ihrem Windows 10 PC betreiben wollen. Wollen wir aber gar nicht …
    Installation
    Also installieren wir mal das richtige
    PS> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force PS> Install-Module -Name DockerMsftProvider -Force PS> Install-Package -Name docker -ProviderName DockerMsftProvider -Force Danach möchte der Server einmal neu starten und wir können mit docker version schauen ob das funktioniert hat.
    PS C:\> docker version Client: Version: 18.09.0 API version: 1.39 Go version: go1.10.3 Git commit: 33a45cd0a2 Built: unknown-buildtime OS/Arch: windows/amd64 Experimental: false Server: Engine: Version: 18.09.0 API version: 1.39 (minimum version 1.24) Go version: go1.10.3 Git commit: 33a45cd0a2 Built: 11/07/2018 00:24:12 OS/Arch: windows/amd64 Experimental: true An der Stelle konfigurieren wir den Dienst erstmal ein wenig. Das kann man prinzipiell auch über eine json-Datei erledigen. Anleitungen dazu findet man genug. Man kann die Parameter aber auch direkt dem Dienst übergeben.
    PS E:\> Stop-Service Docker PS E:\> Remove-Service Docker PS E:\> New-Service -Name Docker -DisplayName "Docker Engine" -StartupType Boot -BinaryPathName "C:\Program Files\Docker\dockerd.exe --run-service -H npipe:// -H 0.0.0.0:2375 --data-root=E:\docker --experimental" PS E:\> Start-Service Docker Für Remove-Service benötigt man allerdings PowerShell Version 6. Die gibt es zwar seit August 2018, ist dennoch nicht im Server 2019 enthalten. Nach dem Neustart des Dienstes legt Docker nun seine benötigte Verzeichnisstruktur unter E:\docker an. Und durch –experimental können wir später –plattform=linux nutzen.
    Nun ist es endlich soweit, wir holen unser erstes Image. Normalerweise würde man das einfach mit
    PS> docker pull microsoft/nanoserver erledigen. Das funktioniert zwar, aber ...
    Das was man dann bekommt ist ein Server 2016 SAC Image. Was per se zwar nicht verkehrt ist, aber im ersten Moment auf einem Server 2019 nicht funktioniert. Hier müsste man dem docker run noch ein --isolation=hyperv mitgeben oder man holt ein neues Image. Für Images die zum Server 2019 passen benötigt man spezifische Tags und kann sich nicht auf den Standard :latest verlassen. Images vom Nanoserver und Windows Server Core holen wir mit.
    PS> docker pull mcr.microsoft.com/windows/nanoserver:1809 PS> docker pull mcr.microsoft.com/windows/servercore:ltsc2019 Anschließend verpassen wir den Images noch neue Tags
    PS> docker image tag mcr.microsoft.com/windows/nanoserver:1809 nanoserver:1809 An dieser Stelle können wir auch schon mal einen Container mit einem der Images starten.
    PS> docker run -it --name testdings microsoft/nanoserver powershell Damit bekommen wir eine PowerShell Instanz in dem laufenden Container und können Dinge tun. Updates installieren, wäre eines dieser Dinge. Das erledigt man normalerweise mit sconfig auf der geöffneten PowerShell.
    In den nächsten Teilen bereiten wir die Build-Umgebung vor, basteln uns ein Dockerfile und bewundern das Ergebnis
  5. Like
    _n4p_ reagierte auf Lewan für ein Blogeintrag, In zwei Jahren zum Fachinformatiker   
    In zwei Jahren zum Fachinformatiker? 
    Geht das überhaupt? 
     
    Nun, das werde ich für dich testen. Es gab schon unzählige Testkarnickel, aber geblogt, hat es hier bis jetzt noch keiner.
    Und genau da fängt mein Blog an. Ich werde dir in regelmäßigen Abständen, offenlegen
    Was ich gelernt habe  Wie mir das Thema gefiel bzw.  Wie verständlich das Thema in der kurzen Zeit vermittelt wurde Welche Hilfsmittel, wie Internet Seiten oder Bücher ich benutzt habe Welche Tips mir mein Dozent mit auf den Weg gegeben hat und Welche besonderen Unterschiede in meinem Betrieb zu anderen Betrieben bzw. zu der rein Schulischen Ausbildung vorliegen Wobei ich bei dem letzten Punkt, auf deine Hilfe angewiesen bin. Nutze die Kommentar Funktion, um mir zu zeigen, dass ich genug Vorwissen gesammelt habe um
    Die IHK-Prüfung zu bestehen Im Praktikum nicht zum Kaffe Kocher verdammt werde und Der wichtigste Punkt. Mit meinem Vorwissen, eine solide Grundlage habe um bei meinem zukünftigen Arbeitgeber, eine attraktive Hilfe zu sein und nicht nur ein Klotz am Bein.  Das ganze ist natürlich für beide Seiten attraktiv zu sehen. Nicht nur ich profitiere von deinen Kommentaren, sondern auch du kannst von meinem Blog profitieren.
    Viele Themen werden mal kurz mal lang durchgerattert und ob es nach zwei Jahren im Kopf geblieben ist, wenn man sich nicht mehr damit beschäftigt, beantwortet sich natürlich von selbst. Je öfter wir unsere grauen Zellen an das Thema leiten, um so mehr Synapsen werden angesprochen und um so weniger gerät ein Thema in Vergessenheit. 
    Du bist schon länger Fachinformatiker und willst uns angehenden Fachinformatikern, mit Rat und Tat bei Seite stehen? 
    Auch du bist eine riesen Bereicherung für meinen Blog. Es gibt genug Themen, die man falsch aufgenommen hat. Dieses falsche Wissen kann in einer mündlichen Prüfung dann das Todesurteil sein. Sollte dir ein falsch formulierter Blog Eintrag auffallen, schreibe es bitte in die Kommentare. Dadurch wird das falsche Wissen nicht im Internet weiter kursieren und die Blog Leser haben dann die Möglichkeit sich durch diesen Blog mit richtigen Ansätzen dem Thema neu zu widmen. 
    Natürlich ist das kein Lehrblog den ich führe, aber eine Zusammenfassung dessen, was mir in meiner Umschulung auf den Weg gegeben wurde. 
    Schließlich ist das Thema ja "in zwei Jahren zum Fachinformatiker, geht das überhaupt?" Und nicht "ich bringe dir in zwei Jahren den Beruf bei" ?
    Somit verabschiede ich mich mit meinem ersten Blog bei dir und gebe dir noch die Fragen auf den Weg
    Hat dich der Blog angesprochen?  War er gut zu lesen oder so anstrengend, dass du froh warst, endlich Licht am Ende des Tunnels gesehen zu haben?   
    Ich freue mich über deine Geduld, deine Zeit und dein Interesse das du in den Beitrag investiert hast. Dein Kommentar wäre das gelbe vom Ei. Ich hoffe auf ein Wiedersehen und das Folgen meines Blogs. 
    Euer Lewan 
  6. Like
    _n4p_ erhielt eine Reaktion von david.r für ein Blogeintrag, Windows Server Container und Docker III   
    Dockerfile
    Damit man nicht mit jedem Container alles neu machen muss, kann man sich über Dockerfiles eigene Images erzeugen. Die hier gezeigte Version ist mehr oder weniger die finale Version. Davor gab es natürlich diverse Fehlversuche sei es wegen eigener Fehler oder weil man manche Dinge auch einfach nicht vermutet hätte. Unter Windows Nanoserver gibt es beispielsweise gar kein msiexec und das msiexec vom Server Core schreibt die Registryeinträge gar nicht oder irgendwohin wo sie später nicht gefunden werden. Mit setx kann man zwar globale Umgebungsvariablen setzen, startet man den Apache aber als Dienst, wird die Pfadeinstellung dennoch nicht genutzt.
    # Wir benutzen unser schon gepulltes Windows Servercore Image FROM servercore:ltsc2019 COPY install /install # Installiert die ODBC Treiber im Image # Wer hier eine Ausgabe zum Debuggen will kann noch "/l! out13.log" anhängen RUN ["msiexec", "/a C:\\install\\msodbcsql_13.msi", "/qn"] RUN ["msiexec", "/a C:\\install\\msodbcsql_17.msi", "/qn"] # Installation von VC Redist - 15 wird bei Server 2019 nicht benötigt RUN ["C:\\install\\vc_17.exe", "/quiet", "/install"] RUN ["C:\\install\\vc_13.exe", "/quiet", "/install"] # Die Registry-Datei für die ODBC Treiber importieren RUN "reg import C:\\install\\odbc.reg" # install brauchen wir nicht mehr RUN "RMDIR /S /Q C:\\install" # /instantclient entspricht dann C:\instantclient im Image COPY instantclient /instantclient # einfach großartig - wenn jemand eine Idee hat wie ich Apache als Service erklären kann wo der instantclient liegt ... ENV PATH="C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\ContainerAdministrator\AppData\Local\Microsoft\WindowsApps;C:\instantclient" # Apache usw. kopieren - *1 COPY webapp /webapp WORKDIR /webapp # wir möchten mit dem Container reden EXPOSE 80 # kopieren von php und der php.conf ins Apache config Verzeichnis - *2 COPY php/php /webapp/php COPY php/php.conf /webapp/Apache24/conf/extra # zum Testen/Debuggen #ENTRYPOINT ["cmd.exe"] # und los geht’s ENTRYPOINT ["C:\\webapp\\Apache24\\bin\\httpd.exe"] Das Dockerfile kommt dann mit in das Build-Verzeichnis und das neue Image kann mit folgendem Befehl erzeugt werden.
    PS E:\build\>docker build -t test . Mit
    PS E:\build\>docker run -it -p 80:80 --name test_container test starten wir den Container und prüfen das alles wie gewünscht funktioniert. Ist das der Fall teilen wir das Dockerfile in 3 Dateien. Das Dockerfile wird dann bei *1 und *2 aufgeteilt. Der erste Teil bleibt wie er ist und wir nennen das Dockerfile core2019. Und bauen ein Image daraus.
    PS E:\build\>docker image build -t core2019 -f .\core2019 . Das zweite Dockerfile sieht dann so aus
    FROM core2019:latest COPY webapp /webapp EXPOSE 80 und das dritte so
    FROM apache_core2019:latest COPY php/php /webapp/php COPY php/php.conf /webapp/Apache24/conf/extra WORKDIR /logodata ENTRYPOINT ["C:\\webapp\\Apache24\\bin\\httpd.exe"]
    Ich habe die Dockerfiles nach dem Image benannt das sie erzeugen. Die weiteren Images baue ich also mit
    PS E:\build\>docker image build -t apache_core2019 -f .\apache_core2019 . PS E:\build\>docker image build -t php_apache_core2019 -f .\php_apache_core2019 . Damit hat man zwar etwas Overhead bei jedem Build, da jedesmal das komplette Verzeichnis zum Buildprozess übergeben wird. Allerdings können wir so sehr einfach andere PHP und/oder Apache Versionen in ein anderes Image packen ohne den Standard zu verlieren oder die grundlegende Installation wiederholen zu müssen.
    Lauf Docker, Lauf!
    Die entstandenen Images kann man nun wieder mit kürzeren Namen taggen und schließlich starten
    PS> docker run --restart unless-stopped -d --name flamara -p 17000:80 -v E:\share\develop:C:\webapp\docroot -v E:\share\config:C:\webapp\docroot\config\ --dns=10.0.0.20 php2019:latest Mit -p mappen wir einen Port des Hosts zu dem freigegebenen Port des Containers. Dann mappen wir mit -v zum einen die Webapplikation selbst ins docroot des Containers und auch die Konfiguration der Software.
    So können wir beliebige Versionen der Software mit der gleichen Konfiguration (Benutzer, Rechte, Datenbankanbindung) in der gleichen Umgebung testen.
    Die nächsten Schritte wären nun, das Ganze mit einem Linux Base-Image zur erstellen und danach automatisierte Builds.
  7. Like
    _n4p_ erhielt eine Reaktion von david.r für ein Blogeintrag, Windows Server Container und Docker II   
    Vorbereitung
    Als nächstes bereiten wir die Build-Umgebung vor. Wir laden Apache, PHP, passende vc_redist (17 und 13), Microsoft ODBC Treiber 13 und 17, SQLSRV5.3, und einen Oracle Instantclient herunter.
    Ich überspringe an dieser Stelle einige Schritte und zeige nur die endgültige Version. Ihr verpasst aber nichts Dramatisches, der Buildprozess wurde nur einige Male verändert und die Verzeichnisstruktur entsprechend angepasst. Der Sinn oder Unsinn wird dann vermutlich klar, wenn wir uns die Dockerfiles ansehen.
    Also legen wir erstmal folgende Struktur an:
    Build ├───install ├───instantclient ├───webapp │   ├───Apache24 │   └───docroot └───php     └───php In install legen wir die VC Redist Installer und die ODBC Treiber MSI-Pakete ab. Ich habe die umbenannt um sie leichter unterscheiden zu können.
    Den Instantclient kann man einfach entpacken und den Inhalt des instantclient_18_3-Verzeichnisses in instantclient ablegen.
    In php/php wird das heruntergeladene PHP entpackt und in webapp/Apache24 der Webserver. Die httpd.conf nach Belieben anpassen, darauf achten das das DocumentRoot webapp/docroot sein soll und noch eine webapp/Apache/conf/extra/php.conf includieren. Die gibt es zwar nicht, das erledigt dann der Buildprozess.
    Die php.conf kommt nach /php und sieht etwa so aus:
    LoadModule php7_module "C:\webapp\php\php7apache2_4.dll" AddType application/x-httpd-php .php PHPIniDir "C:\webapp\php" DirectoryIndex index.php Nun noch PHP konfigurieren und dann sind die Vorbereitungen abgeschlossen.
    Eigentlich ... also quasi schon ...
    Aus irgendeinem Grund werden die Registry-Einträge für die ODBC-Treiber nicht geschrieben. Weder beim Build noch im laufenden Container. Also erstellen wir noch eine odbc.reg und legen die mit nach /install. Die Datei kann man erzeugen, indem man den Schlüssel exportiert. Dazu kann man kurzzeitig die ODBC Treiber auf dem Host installieren.
  8. Like
    _n4p_ erhielt eine Reaktion von david.r für ein Blogeintrag, Windows Server Container und Docker I   
    Einleitung
    Die grundlegende Frage gleich vornweg: Warum sollte man Docker auf einem Windows Server betreiben?
    Nunja, weil man es kann. Außerdem besteht die Infrastruktur bei den meisten unserer Kunden aus MS SQL-Server und Windows Servern auf denen unsere Software installiert wird. Hier könnte man nun argumentieren, dass unsere Software "nur" PHP und Apache benötigt und das zusammen mit PostGreSQL oder ORACLE durchaus auf Linux laufen könnte. Ja, ist richtig, wir möchten aber nicht auch noch irgendwelche Linux Installationen bei unseren Kunden pflegen.
    Sucht man, naiv wie man ist, einfach mal nach "docker windows", landet man früher oder später bei "Docker CE for Window". Hat man das installiert und den ersten Container gestartet, wird einem auffallen das die Container nicht beim Booten starten. Da ist auch nichts falsch konfiguriert, das soll so sein. Dafür gibt es sicherlich Gründe. Diese Version ist für Entwickler gedacht, die Docker auf ihrem Windows 10 PC betreiben wollen. Wollen wir aber gar nicht …
    Installation
    Also installieren wir mal das richtige
    PS> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force PS> Install-Module -Name DockerMsftProvider -Force PS> Install-Package -Name docker -ProviderName DockerMsftProvider -Force Danach möchte der Server einmal neu starten und wir können mit docker version schauen ob das funktioniert hat.
    PS C:\> docker version Client: Version: 18.09.0 API version: 1.39 Go version: go1.10.3 Git commit: 33a45cd0a2 Built: unknown-buildtime OS/Arch: windows/amd64 Experimental: false Server: Engine: Version: 18.09.0 API version: 1.39 (minimum version 1.24) Go version: go1.10.3 Git commit: 33a45cd0a2 Built: 11/07/2018 00:24:12 OS/Arch: windows/amd64 Experimental: true An der Stelle konfigurieren wir den Dienst erstmal ein wenig. Das kann man prinzipiell auch über eine json-Datei erledigen. Anleitungen dazu findet man genug. Man kann die Parameter aber auch direkt dem Dienst übergeben.
    PS E:\> Stop-Service Docker PS E:\> Remove-Service Docker PS E:\> New-Service -Name Docker -DisplayName "Docker Engine" -StartupType Boot -BinaryPathName "C:\Program Files\Docker\dockerd.exe --run-service -H npipe:// -H 0.0.0.0:2375 --data-root=E:\docker --experimental" PS E:\> Start-Service Docker Für Remove-Service benötigt man allerdings PowerShell Version 6. Die gibt es zwar seit August 2018, ist dennoch nicht im Server 2019 enthalten. Nach dem Neustart des Dienstes legt Docker nun seine benötigte Verzeichnisstruktur unter E:\docker an. Und durch –experimental können wir später –plattform=linux nutzen.
    Nun ist es endlich soweit, wir holen unser erstes Image. Normalerweise würde man das einfach mit
    PS> docker pull microsoft/nanoserver erledigen. Das funktioniert zwar, aber ...
    Das was man dann bekommt ist ein Server 2016 SAC Image. Was per se zwar nicht verkehrt ist, aber im ersten Moment auf einem Server 2019 nicht funktioniert. Hier müsste man dem docker run noch ein --isolation=hyperv mitgeben oder man holt ein neues Image. Für Images die zum Server 2019 passen benötigt man spezifische Tags und kann sich nicht auf den Standard :latest verlassen. Images vom Nanoserver und Windows Server Core holen wir mit.
    PS> docker pull mcr.microsoft.com/windows/nanoserver:1809 PS> docker pull mcr.microsoft.com/windows/servercore:ltsc2019 Anschließend verpassen wir den Images noch neue Tags
    PS> docker image tag mcr.microsoft.com/windows/nanoserver:1809 nanoserver:1809 An dieser Stelle können wir auch schon mal einen Container mit einem der Images starten.
    PS> docker run -it --name testdings microsoft/nanoserver powershell Damit bekommen wir eine PowerShell Instanz in dem laufenden Container und können Dinge tun. Updates installieren, wäre eines dieser Dinge. Das erledigt man normalerweise mit sconfig auf der geöffneten PowerShell.
    In den nächsten Teilen bereiten wir die Build-Umgebung vor, basteln uns ein Dockerfile und bewundern das Ergebnis
  9. Like
    _n4p_ erhielt eine Reaktion von KeeperOfCoffee für ein Blogeintrag, Windows Server Container und Docker II   
    Vorbereitung
    Als nächstes bereiten wir die Build-Umgebung vor. Wir laden Apache, PHP, passende vc_redist (17 und 13), Microsoft ODBC Treiber 13 und 17, SQLSRV5.3, und einen Oracle Instantclient herunter.
    Ich überspringe an dieser Stelle einige Schritte und zeige nur die endgültige Version. Ihr verpasst aber nichts Dramatisches, der Buildprozess wurde nur einige Male verändert und die Verzeichnisstruktur entsprechend angepasst. Der Sinn oder Unsinn wird dann vermutlich klar, wenn wir uns die Dockerfiles ansehen.
    Also legen wir erstmal folgende Struktur an:
    Build ├───install ├───instantclient ├───webapp │   ├───Apache24 │   └───docroot └───php     └───php In install legen wir die VC Redist Installer und die ODBC Treiber MSI-Pakete ab. Ich habe die umbenannt um sie leichter unterscheiden zu können.
    Den Instantclient kann man einfach entpacken und den Inhalt des instantclient_18_3-Verzeichnisses in instantclient ablegen.
    In php/php wird das heruntergeladene PHP entpackt und in webapp/Apache24 der Webserver. Die httpd.conf nach Belieben anpassen, darauf achten das das DocumentRoot webapp/docroot sein soll und noch eine webapp/Apache/conf/extra/php.conf includieren. Die gibt es zwar nicht, das erledigt dann der Buildprozess.
    Die php.conf kommt nach /php und sieht etwa so aus:
    LoadModule php7_module "C:\webapp\php\php7apache2_4.dll" AddType application/x-httpd-php .php PHPIniDir "C:\webapp\php" DirectoryIndex index.php Nun noch PHP konfigurieren und dann sind die Vorbereitungen abgeschlossen.
    Eigentlich ... also quasi schon ...
    Aus irgendeinem Grund werden die Registry-Einträge für die ODBC-Treiber nicht geschrieben. Weder beim Build noch im laufenden Container. Also erstellen wir noch eine odbc.reg und legen die mit nach /install. Die Datei kann man erzeugen, indem man den Schlüssel exportiert. Dazu kann man kurzzeitig die ODBC Treiber auf dem Host installieren.
  10. Like
    _n4p_ erhielt eine Reaktion von KeeperOfCoffee für ein Blogeintrag, Windows Server Container und Docker I   
    Einleitung
    Die grundlegende Frage gleich vornweg: Warum sollte man Docker auf einem Windows Server betreiben?
    Nunja, weil man es kann. Außerdem besteht die Infrastruktur bei den meisten unserer Kunden aus MS SQL-Server und Windows Servern auf denen unsere Software installiert wird. Hier könnte man nun argumentieren, dass unsere Software "nur" PHP und Apache benötigt und das zusammen mit PostGreSQL oder ORACLE durchaus auf Linux laufen könnte. Ja, ist richtig, wir möchten aber nicht auch noch irgendwelche Linux Installationen bei unseren Kunden pflegen.
    Sucht man, naiv wie man ist, einfach mal nach "docker windows", landet man früher oder später bei "Docker CE for Window". Hat man das installiert und den ersten Container gestartet, wird einem auffallen das die Container nicht beim Booten starten. Da ist auch nichts falsch konfiguriert, das soll so sein. Dafür gibt es sicherlich Gründe. Diese Version ist für Entwickler gedacht, die Docker auf ihrem Windows 10 PC betreiben wollen. Wollen wir aber gar nicht …
    Installation
    Also installieren wir mal das richtige
    PS> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force PS> Install-Module -Name DockerMsftProvider -Force PS> Install-Package -Name docker -ProviderName DockerMsftProvider -Force Danach möchte der Server einmal neu starten und wir können mit docker version schauen ob das funktioniert hat.
    PS C:\> docker version Client: Version: 18.09.0 API version: 1.39 Go version: go1.10.3 Git commit: 33a45cd0a2 Built: unknown-buildtime OS/Arch: windows/amd64 Experimental: false Server: Engine: Version: 18.09.0 API version: 1.39 (minimum version 1.24) Go version: go1.10.3 Git commit: 33a45cd0a2 Built: 11/07/2018 00:24:12 OS/Arch: windows/amd64 Experimental: true An der Stelle konfigurieren wir den Dienst erstmal ein wenig. Das kann man prinzipiell auch über eine json-Datei erledigen. Anleitungen dazu findet man genug. Man kann die Parameter aber auch direkt dem Dienst übergeben.
    PS E:\> Stop-Service Docker PS E:\> Remove-Service Docker PS E:\> New-Service -Name Docker -DisplayName "Docker Engine" -StartupType Boot -BinaryPathName "C:\Program Files\Docker\dockerd.exe --run-service -H npipe:// -H 0.0.0.0:2375 --data-root=E:\docker --experimental" PS E:\> Start-Service Docker Für Remove-Service benötigt man allerdings PowerShell Version 6. Die gibt es zwar seit August 2018, ist dennoch nicht im Server 2019 enthalten. Nach dem Neustart des Dienstes legt Docker nun seine benötigte Verzeichnisstruktur unter E:\docker an. Und durch –experimental können wir später –plattform=linux nutzen.
    Nun ist es endlich soweit, wir holen unser erstes Image. Normalerweise würde man das einfach mit
    PS> docker pull microsoft/nanoserver erledigen. Das funktioniert zwar, aber ...
    Das was man dann bekommt ist ein Server 2016 SAC Image. Was per se zwar nicht verkehrt ist, aber im ersten Moment auf einem Server 2019 nicht funktioniert. Hier müsste man dem docker run noch ein --isolation=hyperv mitgeben oder man holt ein neues Image. Für Images die zum Server 2019 passen benötigt man spezifische Tags und kann sich nicht auf den Standard :latest verlassen. Images vom Nanoserver und Windows Server Core holen wir mit.
    PS> docker pull mcr.microsoft.com/windows/nanoserver:1809 PS> docker pull mcr.microsoft.com/windows/servercore:ltsc2019 Anschließend verpassen wir den Images noch neue Tags
    PS> docker image tag mcr.microsoft.com/windows/nanoserver:1809 nanoserver:1809 An dieser Stelle können wir auch schon mal einen Container mit einem der Images starten.
    PS> docker run -it --name testdings microsoft/nanoserver powershell Damit bekommen wir eine PowerShell Instanz in dem laufenden Container und können Dinge tun. Updates installieren, wäre eines dieser Dinge. Das erledigt man normalerweise mit sconfig auf der geöffneten PowerShell.
    In den nächsten Teilen bereiten wir die Build-Umgebung vor, basteln uns ein Dockerfile und bewundern das Ergebnis
  11. Like
    _n4p_ erhielt eine Reaktion von StefanE für ein Blogeintrag, Windows Server Container und Docker I   
    Einleitung
    Die grundlegende Frage gleich vornweg: Warum sollte man Docker auf einem Windows Server betreiben?
    Nunja, weil man es kann. Außerdem besteht die Infrastruktur bei den meisten unserer Kunden aus MS SQL-Server und Windows Servern auf denen unsere Software installiert wird. Hier könnte man nun argumentieren, dass unsere Software "nur" PHP und Apache benötigt und das zusammen mit PostGreSQL oder ORACLE durchaus auf Linux laufen könnte. Ja, ist richtig, wir möchten aber nicht auch noch irgendwelche Linux Installationen bei unseren Kunden pflegen.
    Sucht man, naiv wie man ist, einfach mal nach "docker windows", landet man früher oder später bei "Docker CE for Window". Hat man das installiert und den ersten Container gestartet, wird einem auffallen das die Container nicht beim Booten starten. Da ist auch nichts falsch konfiguriert, das soll so sein. Dafür gibt es sicherlich Gründe. Diese Version ist für Entwickler gedacht, die Docker auf ihrem Windows 10 PC betreiben wollen. Wollen wir aber gar nicht …
    Installation
    Also installieren wir mal das richtige
    PS> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force PS> Install-Module -Name DockerMsftProvider -Force PS> Install-Package -Name docker -ProviderName DockerMsftProvider -Force Danach möchte der Server einmal neu starten und wir können mit docker version schauen ob das funktioniert hat.
    PS C:\> docker version Client: Version: 18.09.0 API version: 1.39 Go version: go1.10.3 Git commit: 33a45cd0a2 Built: unknown-buildtime OS/Arch: windows/amd64 Experimental: false Server: Engine: Version: 18.09.0 API version: 1.39 (minimum version 1.24) Go version: go1.10.3 Git commit: 33a45cd0a2 Built: 11/07/2018 00:24:12 OS/Arch: windows/amd64 Experimental: true An der Stelle konfigurieren wir den Dienst erstmal ein wenig. Das kann man prinzipiell auch über eine json-Datei erledigen. Anleitungen dazu findet man genug. Man kann die Parameter aber auch direkt dem Dienst übergeben.
    PS E:\> Stop-Service Docker PS E:\> Remove-Service Docker PS E:\> New-Service -Name Docker -DisplayName "Docker Engine" -StartupType Boot -BinaryPathName "C:\Program Files\Docker\dockerd.exe --run-service -H npipe:// -H 0.0.0.0:2375 --data-root=E:\docker --experimental" PS E:\> Start-Service Docker Für Remove-Service benötigt man allerdings PowerShell Version 6. Die gibt es zwar seit August 2018, ist dennoch nicht im Server 2019 enthalten. Nach dem Neustart des Dienstes legt Docker nun seine benötigte Verzeichnisstruktur unter E:\docker an. Und durch –experimental können wir später –plattform=linux nutzen.
    Nun ist es endlich soweit, wir holen unser erstes Image. Normalerweise würde man das einfach mit
    PS> docker pull microsoft/nanoserver erledigen. Das funktioniert zwar, aber ...
    Das was man dann bekommt ist ein Server 2016 SAC Image. Was per se zwar nicht verkehrt ist, aber im ersten Moment auf einem Server 2019 nicht funktioniert. Hier müsste man dem docker run noch ein --isolation=hyperv mitgeben oder man holt ein neues Image. Für Images die zum Server 2019 passen benötigt man spezifische Tags und kann sich nicht auf den Standard :latest verlassen. Images vom Nanoserver und Windows Server Core holen wir mit.
    PS> docker pull mcr.microsoft.com/windows/nanoserver:1809 PS> docker pull mcr.microsoft.com/windows/servercore:ltsc2019 Anschließend verpassen wir den Images noch neue Tags
    PS> docker image tag mcr.microsoft.com/windows/nanoserver:1809 nanoserver:1809 An dieser Stelle können wir auch schon mal einen Container mit einem der Images starten.
    PS> docker run -it --name testdings microsoft/nanoserver powershell Damit bekommen wir eine PowerShell Instanz in dem laufenden Container und können Dinge tun. Updates installieren, wäre eines dieser Dinge. Das erledigt man normalerweise mit sconfig auf der geöffneten PowerShell.
    In den nächsten Teilen bereiten wir die Build-Umgebung vor, basteln uns ein Dockerfile und bewundern das Ergebnis
  12. Like
    _n4p_ erhielt eine Reaktion von Listener für ein Blogeintrag, Windows Server Container und Docker I   
    Einleitung
    Die grundlegende Frage gleich vornweg: Warum sollte man Docker auf einem Windows Server betreiben?
    Nunja, weil man es kann. Außerdem besteht die Infrastruktur bei den meisten unserer Kunden aus MS SQL-Server und Windows Servern auf denen unsere Software installiert wird. Hier könnte man nun argumentieren, dass unsere Software "nur" PHP und Apache benötigt und das zusammen mit PostGreSQL oder ORACLE durchaus auf Linux laufen könnte. Ja, ist richtig, wir möchten aber nicht auch noch irgendwelche Linux Installationen bei unseren Kunden pflegen.
    Sucht man, naiv wie man ist, einfach mal nach "docker windows", landet man früher oder später bei "Docker CE for Window". Hat man das installiert und den ersten Container gestartet, wird einem auffallen das die Container nicht beim Booten starten. Da ist auch nichts falsch konfiguriert, das soll so sein. Dafür gibt es sicherlich Gründe. Diese Version ist für Entwickler gedacht, die Docker auf ihrem Windows 10 PC betreiben wollen. Wollen wir aber gar nicht …
    Installation
    Also installieren wir mal das richtige
    PS> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force PS> Install-Module -Name DockerMsftProvider -Force PS> Install-Package -Name docker -ProviderName DockerMsftProvider -Force Danach möchte der Server einmal neu starten und wir können mit docker version schauen ob das funktioniert hat.
    PS C:\> docker version Client: Version: 18.09.0 API version: 1.39 Go version: go1.10.3 Git commit: 33a45cd0a2 Built: unknown-buildtime OS/Arch: windows/amd64 Experimental: false Server: Engine: Version: 18.09.0 API version: 1.39 (minimum version 1.24) Go version: go1.10.3 Git commit: 33a45cd0a2 Built: 11/07/2018 00:24:12 OS/Arch: windows/amd64 Experimental: true An der Stelle konfigurieren wir den Dienst erstmal ein wenig. Das kann man prinzipiell auch über eine json-Datei erledigen. Anleitungen dazu findet man genug. Man kann die Parameter aber auch direkt dem Dienst übergeben.
    PS E:\> Stop-Service Docker PS E:\> Remove-Service Docker PS E:\> New-Service -Name Docker -DisplayName "Docker Engine" -StartupType Boot -BinaryPathName "C:\Program Files\Docker\dockerd.exe --run-service -H npipe:// -H 0.0.0.0:2375 --data-root=E:\docker --experimental" PS E:\> Start-Service Docker Für Remove-Service benötigt man allerdings PowerShell Version 6. Die gibt es zwar seit August 2018, ist dennoch nicht im Server 2019 enthalten. Nach dem Neustart des Dienstes legt Docker nun seine benötigte Verzeichnisstruktur unter E:\docker an. Und durch –experimental können wir später –plattform=linux nutzen.
    Nun ist es endlich soweit, wir holen unser erstes Image. Normalerweise würde man das einfach mit
    PS> docker pull microsoft/nanoserver erledigen. Das funktioniert zwar, aber ...
    Das was man dann bekommt ist ein Server 2016 SAC Image. Was per se zwar nicht verkehrt ist, aber im ersten Moment auf einem Server 2019 nicht funktioniert. Hier müsste man dem docker run noch ein --isolation=hyperv mitgeben oder man holt ein neues Image. Für Images die zum Server 2019 passen benötigt man spezifische Tags und kann sich nicht auf den Standard :latest verlassen. Images vom Nanoserver und Windows Server Core holen wir mit.
    PS> docker pull mcr.microsoft.com/windows/nanoserver:1809 PS> docker pull mcr.microsoft.com/windows/servercore:ltsc2019 Anschließend verpassen wir den Images noch neue Tags
    PS> docker image tag mcr.microsoft.com/windows/nanoserver:1809 nanoserver:1809 An dieser Stelle können wir auch schon mal einen Container mit einem der Images starten.
    PS> docker run -it --name testdings microsoft/nanoserver powershell Damit bekommen wir eine PowerShell Instanz in dem laufenden Container und können Dinge tun. Updates installieren, wäre eines dieser Dinge. Das erledigt man normalerweise mit sconfig auf der geöffneten PowerShell.
    In den nächsten Teilen bereiten wir die Build-Umgebung vor, basteln uns ein Dockerfile und bewundern das Ergebnis

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...