Mai 2019
Band 34, Nummer 5
[Data Points]
EF Core in einer containerisierten Docker-App, Teil 2
Von Julie Lerman
.jpg "Julie Lerman")
In der Kolumne des letzten Monats (msdn.com/magazine/mt833405) habe ich ein ASP.NET Core-API-Projekt erstellt, das in einem Docker-Container ausgeführt wird. Das Projekt verwendet EF Core, um Daten persistent zu speichern. In dieser Kolumne habe ich damit begonnen, SQL Server LocalDB zu verwenden. Als es aber an der Zeit war, die Anwendung innerhalb des Docker-Containers auszuführen, stieß ich auf einen Fehler, weil das aktuelle Setup davon ausging, dass SQL Server LocalDB innerhalb des Containers vorhanden war. Als schnelle Lösung wechselte ich zu SQLite, das installiert wird, wenn das neue Projekt im Container erstellt wird. Mit diesem Ansatz konnten Sie sehen, wie die vollständige Projektmappe erfolgreich debuggt werden konnte.
Der Wechsel zu SQLite war einfach ein Mittel, um einen sofortigen Erfolg zu erreichen. Setzen wir die Reise fort, indem wir uns mit den richtigen produktionstauglichen Lösungen für SQL Server bei der Veröffentlichung einer API in einem Docker-Image befassen. Diese Kolumne konzentriert sich auf die Verwendung einer konsistent verfügbaren Azure SQL-Datenbank, die von überall aus verwendet werden kann.
Verweisen der API auf Azure SQL-Datenbank
Mein Ausgangspunkt ist die Projektmappe, wie ich sie am Ende meiner vorherigen Kolumne hinterlassen habe. Wenn Sie diese Kolumne noch nicht gelesen haben, sollten Sie vielleicht dort beginnen, um den Kontext zu verstehen. Im Laufe dieses Artikels werde ich diese Projektmappe Schritt für Schritt weiterentwickeln.
EF Core kann zwar eine Datenbank für Sie unter Azure SQL-Datenbank erstellen, der SQL-Server muss jedoch bereits vorhanden sein. Ich habe bereits einige SQL-Server unter Azure eingerichtet, also werde ich einen davon für die Demos dieser Kolumne verwenden.
Zuerst füge ich in der Datei „appsettings.json“ eine neue Verbindungszeichenfolge namens MagsConnectionAzSql hinzu, die auf diesen Server verweist. Diese Datei enthält bereits Verbindungszeichenfolgen, die ich in Teil 1 verwendet habe. Ich habe die langen Zeilen zur besseren Lesbarkeit umbrochen, obwohl JSON keine Zeilenschaltungen verwendet. Ich binde auch falsche Anmeldeinformationen ein:
"ConnectionStrings": {
"MagsConnectionMssql":"Server=(localdb)\\mssqllocaldb;
Database=DP0419Mags;Trusted_Connection=True;",
"MagsConnectionSqlite": "Filename=DP0419Mags.db;",
"MagsConnectionAzSql": "Server=tcp:msdnmaglerman.database.windows.net,1433;
Initial Catalog=DP0419Mags;Persist Security Info=False;
User ID=lerman;Password=eiluj;
MultipleActiveResultSets=False;Encrypt=True;
TrustServerCertificate=False;Connection Timeout=30;"
Dann ändere ich die DbContext-Konfiguration in der ConfigureServices-Methode der Startdatei so, dass der SQL Server-Anbieter und diese Verbindungszeichenfolge verwendet werden:
services.AddDbContext<MagContext>(options =>
options.UseSqlServer(
Configuration.GetConnectionString("MagsConnectionAzSql")));
Dies ermöglicht es EF Core-Migrationen, die Verbindungszeichenfolge zur Entwurfszeit zu finden, sodass ich alle benötigten Befehle ausführen kann. Zur Laufzeit kann die App die Verbindungszeichenfolge ebenfalls finden. Da ich zuletzt mit SQLite gearbeitet habe, muss ich die Migrationen zurücksetzen, was in meiner Demo bedeutet, den Ordner „Migrations“ zu löschen und „add-migration initSqlAz“ auszuführen, um die ordnungsgemäß beschriebene Migration für die Datenbank zu erhalten.
Sobald die Migration vorhanden ist, führe ich die App mithilfe des Docker-Profils aus. Dies wird mir beweisen, dass die Migrate-Methode in „program.cs“ in der Lage ist, die Datenbank in der Cloud zu erstellen und der Controller sie wie erwartet abfragen kann – alles aus dem Docker-Container heraus. Rechnen Sie mit einer kurzen Verzögerung, wenn die App die Migration zum ersten Mal ausführt und die Datenbank erstellen muss. Wenn dies erledigt ist, gibt der Browser nicht nur die drei Magazine aus, mit denen ich das Seeding der Datenbank (in der vorherigen Kolumne) durchgeführt habe, wie Abbildung 1 zeigt, sondern ich kann auch die Datenbank sehen, die sowohl im Azure-Portal als auch im Objekt-Explorer von Visual Studio SQL Server aufgeführt wird.
.png "Die Ausgabe der API, die drei Magazine auflistet, die mithilfe von Seeding in DbContext definiert wurden")
Abbildung 1: Die Ausgabe der API, die drei Magazine auflistet, die mithilfe von Seeding in DbContext definiert wurden
Beachten Sie, dass die Standardkonfiguration der von EF Core erstellten Datenbank mit dem folgenden Tarif eingerichtet wurde: Standard S0: 10 DTUs. Sie können daran Änderungen im Portal oder bei der Verwendung der Azure CLI für eine Produktions-App vornehmen. Für die Produktion möchten Sie die Datenbank wahrscheinlich explizit erstellen, um sicherzustellen, dass ihre Einstellungen auf Ihre Bedürfnisse abgestimmt sind. Dann können Sie EF Core-Migrationen verwenden, um das Schema zu verwalten.
Überlegungen zur Behandlung von Geheimnissen
Obwohl dies so gut funktioniert hat, ist es noch nicht reif für die Produktion. Es müssen einige Probleme berücksichtigt werden.
Die erste Problem besteht darin, dass die Verbindungszeichenfolge und die Geheimnisse in der Datei „appsettings.json“ hartcodiert sind. Es ist einfach genug, diese Verbindungszeichenfolge in der JSON-Datei zu ändern, ohne das Projekt neu kompilieren zu müssen, sodass „hartcodiert“ ein wenig übertrieben ist. Dies ist aber nicht dynamisch, was Docker betrifft, da die appsettings-Datei in das Docker-Image „eingebrannt“ wird. Wahrscheinlich möchten Sie mehr Kontrolle über die Verbindungszeichenfolgen für Entwicklung, Staging, Tests und Produktion haben. Das ist kein neues Problem und es gibt schon seit geraumer Zeit verschiedene Lösungen dafür. In Bezug auf die Sicherung der Geheimnisse kann das neue Geheimnisverwaltungstool in ASP.NET Core während der Entwicklung helfen. Weitere Informationen finden Sie in der Dokumentation unter bit.ly/2HeVgVr. Außerdem ist die Datei „appsettings.json“ eine Textdatei, und jeder kann sie aus Ihrer Quellcodeverwaltung lesen, wenn Sie sie versehentlich zusammen mit einer App in ein öffentliches Repository pushen.
Ein besserer Weg für die containerisierte Lösung ist die Verwendung von Docker-Umgebungsvariablen, die die App zur Laufzeit lesen kann, während sie weiterhin in der Lage ist, Migrationsbefehle zur Entwurfszeit auszuführen. Dies gibt Ihnen außerdem die Flexibilität, Werte für diese Variablen dynamisch bereitzustellen.
Hier ist der Plan: Ich werde SQL Server LocalDB zur Entwurfszeit verwenden, ebenso wie zum Testen der App „on metal“, also beim Debuggen mit den Kestrel- oder IIS-Servern. Und da LocalDB keine Anmeldeinformationen benötigt, muss ich mir keine Sorgen um Geheimnisse in der Verbindungszeichenfolge machen. Um die App lokal in Docker auszuführen und zu debuggen, kann ich zu einem SQL-Server in meinem Netzwerk wechseln oder auf die Azure SQL-Datenbank verweisen. Schließlich werde ich für die Produktionsversion der containerisierten App sicher sein, dass sie auf die Azure SQL-Datenbank verweist. In der gesamten App können Sie sehen, wie Sie Windows- und Docker-Umgebungsvariablen verwenden können, um Ihre Geheimnisse geheim zu halten.
Und hier ist etwas, das sehr praktisch ist: Da alle diese Ansätze eine Variante von SQL Server verwenden, kann ich immer den gleichen Anbieter nutzen: Microsoft.EntityFrameworkCore.SqlServer.
Verschieben der Entwicklungs-Verbindungszeichenfolge in die Entwicklungseinstellungen
ASP.NET Core verwendet standardmäßig die Einstellungsdatei „appsettings.Development.json“, wenn die Ausführung in Visual Studio erfolgt, aber in der Produktion wird standardmäßig „appsettings.json“ verwendet.
Ich entferne den gesamten Abschnitt connectionStrings aus „appsettings.json“ und füge stattdessen die LocalDB-Verbindungszeichenfolge in „appsettings.Development.json“ hinzu. Sie finden diese Datei, wenn Sie das Pfeilsymbol neben „appSettings.json“ im Projektmappen-Explorer erweitern:
"ConnectionStrings": {
"MagsConnectionMssql":
"Server=(localdb)\\mssqllocaldb;Database=
DP0419Mags;Trusted_Connection=True;"
}
Da ich möchte, dass die App sowohl diese Verbindungszeichenfolge zur Entwurfszeit als auch die von der Dockerfile-Datei zur Laufzeit bereitgestellte Umgebungsvariable lesen kann, muss ich eine andere Syntax für die UseSqlServer-Optionen verwenden. Zurzeit (und am häufigsten) verwenden Sie Configuration.GetConnectionString, um die Zeichenfolge aus appsettings-Dateien zu lesen. Das funktioniert jedoch nicht für Umgebungsvariablen, unabhängig davon, ob sie aus Windows oder Docker stammen. GetConnectionString ist eine Hilfsmethode, die einen direkten Verweis auf den Eigenschaftsnamen ersetzt.
Aber ich kann sowohl die appsettings-Werte als auch beliebige Umgebungswerte als Schlüssel-Wert-Paare mithilfe dieser Syntax lesen:
services.AddDbContext<MagContext>(options =>
options.UseSqlServer(
Configuration["ConnectionStrings:MagsConnectionMssql"]));
Lassen Sie uns überprüfen, ob EF Core-Migrationen die Verbindungszeichenfolge in „appsettings.Development.json“ finden können. Dazu können Sie den PowerShell-Migrationsbefehl Get-DbContext ausführen. Dies zwingt EF Core, die gleiche Arbeit wie bei allen anderen Migrationsbefehlen zu verrichten, und führt zu einer Ausgabe, die den Anbieternamen, den Datenbanknamen und die Datenquelle anzeigt:
providerName databaseName dataSource options
------------ ------------ ---------- -------
Microsoft.EntityFrameworkCore.SqlServer DP0419Mags (localdb)\mssqllocaldb None
Erstellen einer Verbindungszeichenfolge ausschließlich für Docker
Ich weiß jetzt, dass appsettings zur Entwurfszeit funktioniert. Wie wäre es, wenn Docker die alternative Verbindungszeichenfolge ermitteln kann, wenn der Container ausgeführt wird, ohne dass „startup.cs“ geändert werden muss, während Sie hin und her wechseln?
Es ist hilfreich zu wissen, dass die CreateWebHostBuilder-Methode, die in „program.cs“ aufgerufen wird, AddEnvironmentVariables aufruft, um verfügbare Umgebungsvariablen zu lesen und als Schlüssel-Wert-Paare in Konfigurationsdaten zu speichern.
Docker verfügt über einen Befehl namens ENV, mit dem Sie ein Schlüssel-Wert-Paar festlegen können. Ich beginne, indem ich diesen Befehl in der Dockerfile-Datei hartcodiere. Ich kann einen neuen Schlüssel mit dem gleichen Namen wie in der JSON-Datei festlegen, was von der UseSqlServer-Konfiguration erwartet wird. Ich kann sogar den Doppelpunkt in den Namen des Schlüssels aufnehmen. Ich füge meine ENV-Variablen in die Datei ein, bevor das Buildimage erstellt wird. Abbildung 2 zeigt die Dockerfile-Datei einschließlich der neuen ENV-Variablen. Ich habe den Inhalt dieser Datei in Teil 1 dieser Serie beschrieben, falls Sie dies zur Auffrischung noch einmal nachlesen möchten. Beachten Sie, dass ich die Verbindungszeichenfolge hier zur besseren Lesbarkeit abgekürzt habe.
Abbildung 2: Die Dockerfile-Datei für das DataAPIDocker-Projekt mit der eingefügten Verbindungszeichenfolge
FROM microsoft/dotnet:2.2-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80
ENV ConnectionStrings:MagsConnectionMssql=
"Server=tcp:msdnmaglerman.database.windows.net ...”
FROM microsoft/dotnet:2.2-sdk AS build
WORKDIR /src
COPY ["DataAPIDocker/DataAPIDocker.csproj", "DataAPIDocker/"]
RUN dotnet restore "DataAPIDocker/DataAPIDocker.csproj"
COPY . .
WORKDIR "/src/DataAPIDocker"
RUN dotnet build "DataAPIDocker.csproj" -c Release -o /app
FROM build AS publish
RUN dotnet publish "DataAPIDocker.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "DataAPIDocker.dll"]
Sehen wir uns an, welche Auswirkungen dies hat. Stellen Sie sicher, dass das Debugprofil auf Docker verweist, und lassen Sie uns diesmal tatsächlich debuggen. Ich lege einen Breakpoint direkt nach dem AddDbContext-Befehl in „Startup.cs“ fest und debugge. Anschließend prüfe ich den Wert von Configuration["ConnectionStrings:MagsConnectionMssql"]. Ich kann sehen, dass jetzt die Azure SQL-Datenbank-Verbindungszeichenfolge zurückgegeben wird, nicht die LocalDb-Verbindungszeichenfolge. Das Debuggen aller verfügbaren Konfigurationsdaten zeigt mir, dass die appsettings-Verbindungszeichenfolge auch in das Konfigurationsobjekt geladen wird. Aber wie Randy Patterson in seinem Blogbeitrag unter bit.ly/2F5jfE8 erläutert, überschreibt die letzte Einstellung frühere Einstellungen. Und Umgebungsvariablen werden nach appsettings gelesen. Obwohl es also zwei ConnectionStrings:MagsConnectionMssql-Werte gibt, ist der in der Dockerfile-Datei angegebene Wert der Wert, der verwendet wird. Wenn Sie dies in Kestrel oder IIS ausführen würden, würde die Dockerfile-Datei nicht ausgeführt, und ihre Umgebungsvariablen wären in der Konfiguration nicht vorhanden.
Erstellen von Platzhaltern für die Geheimnisse
Aber die ENV-Variable ist nicht variabel. Da sie hartcodiert ist, ist sie zurzeit nur statisch. Denken Sie außerdem daran, dass sie noch immer meine Geheimnisse (Anmeldung und Kennwort) enthält. Anstatt sie in der Verbindungszeichenfolge zu verwenden, werde ich damit beginnen, diese beiden Geheimnisse in ihre eigenen ENV-Variablen zu extrahieren. Für die Platzhalternamen verwende ich ENVID und ENVPW. Dann erstelle ich zwei weitere ENV-Variablen in der Dockerfile-Datei für die Benutzer-ID und das Kennwort und gebe als ersten Schritt deren Werte direkt an:
ENV ConnectionStrings:MagsConnectionAzSql=
"Server=tcp:msdnmaglerman.database.windows.net,1433;
Initial Catalog=DP0419Mags;
User ID=ENVID;Password=ENVPW; [etc...]
ENV DB_UserId="lerman"
ENV DB_PW="eiluj"
Zurück in ConfigureServices von „Startup.cs“ lese ich alle drei Umgebungsvariablen und erstelle die Verbindungszeichenfolge mit ihren Anmeldeinformationen:
var config = new StringBuilder
(Configuration[“ConnectionStrings:MagsConnectionMssql”]);
string conn = config.Replace(“ENVID”, Configuration[“DB_UserId”])
.Replace(“ENVPW”, Configuration[“DB_PW”])
.ToString();
services.AddDbContext<MagContext>(options => options.UseSqlServer(conn));
Dies ist ganz einfach, da sich alle benötigten Werte in der Dockerfile-Datei befinden. Aber noch immer sind die Variablen statisch, und die Geheimnisse werden in der Dockerfile-Datei offengelegt.
Verschieben der Geheimnisse aus der Dockerfile-Datei in Docker-Compose
Da ein Docker-Container nur auf Umgebungsvariablen innerhalb des Containers zugreifen kann, bietet mein aktuelles Setup keine Möglichkeit, den Wert des Kennworts oder anderer in der Dockerfile-Datei angegebener ENV-Variablen zu definieren. Aber es gibt eine Möglichkeit, die es Ihnen ermöglicht, Ihre Docker-Expertise noch ein wenig zu erweitern. Docker verfügt über ein Feature namens Docker Compose, das Ihnen die Arbeit mit mehreren Images ermöglicht. Dies wird durch eine docker-compose-Anweisungsdatei gesteuert, die eine oder mehrere Dockerfile-Dateien auslösen und ausführen kann, wobei jede Dockerfile-Datei ihr eigenes Docker-Image steuert. Zurzeit verwende ich nur ein einziges Image und bleibe auch dabei. Aber ich kann Docker Compose trotzdem nutzen, um Werte an die Umgebungsvariablen des Images zu übergeben.
Warum ist das so wichtig? Es erlaubt mir, meine Geheimnisse sowohl aus der Dockerfile-Datei als auch aus dem Image herauszuhalten. Ich kann die Geheimnisse beim Starten der Containerinstanz zusammen mit allen dynamischen Konfigurationsinformationen (z.B. variierenden Verbindungszeichenfolgen) übergeben. Es gibt einen ausgezeichneten Artikel zu diesem Thema unter bit.ly/2Uuhu8F, den ich sehr hilfreich gefunden habe.
Das Verwenden einer docker-compose-Datei zur Koordination mehrerer Container wird als Containerorchestrierung bezeichnet. Die Visual Studio-Tools für Docker können Sie dabei unterstützen. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt, und wählen Sie dann „Hinzufügen“ und „Unterstützung für Containerorchestrator“ aus. Es wird ein Dropdownmenü angezeigt, in dem Sie „Docker Compose“ und Linux als Zielbetriebssystem auswählen sollten, wenn Sie dazu aufgefordert werden. Da die Dockerfile-Datei bereits vorhanden ist, werden Sie gefragt, ob Sie sie umbenennen und eine neue Dockerfile-Datei erstellen möchten. Beantworten Sie diese Frage mit „Nein“, damit die vorhandene Dockerfile-Datei erhalten bleibt. Anschließend werden Sie gefragt, ob Sie die ausgeblendete DOCKERIGNORE-Datei überschreiben möchten. Da Sie diese Datei nicht bearbeitet haben, sind beide Optionen in Ordnung.
Wenn dieser Vorgang abgeschlossen ist, sehen Sie einen neuen Projektmappenordner namens „docker-compose“ mit zwei Dateien: „.dockerignore“ und „docker-compose.yml“. Die Erweiterung „YML“ bezieht sich auf die YAML-Sprache (yaml.org), ein sehr schlankes Textformat, das auf Einzügen basiert, um das Dateischema auszudrücken.
Die Tools haben Folgendes in „docker-compose.yml“ erstellt:
version: '3.4'
services:
dataapidocker:
image: ${DOCKER_REGISTRY-} dataapidocker
build:
context: .
dockerfile: DataAPIDocker/Dockerfile
Es ist nur ein Dienst vorhanden: für das dataapidocker-Projekt. Er merkt sich den Speicherort der Docker-Datei und den Imagenamen „dataapidocker“ für die spätere Verwendung, wenn es Zeit ist, dieses Image zu erstellen.
Es gibt viele Möglichkeiten, mit docker-compose Umgebungsvariablen in einen Container zu übergeben (dockr.ly/2TwfZub). Ich beginne, indem ich die Variable direkt in die Datei „docker-compose.yml“ einfüge. Zuerst füge ich einen Umgebungsabschnitt innerhalb des dataapidocker-Diensts hinzu – auf der gleichen Ebene wie „image“ und „build“. Dann definiere ich innerhalb des neuen Abschnitts die DP_PW-Variable mit dem hier gezeigten spezifischen Format:
version: '3.4'
services:
dataapidocker :
image: ${DOCKER_REGISTRY-}dataapidocker
build:
context: .
dockerfile: DataAPIDocker/Dockerfile
environment:
- DB_PW=eiluj
Vergessen Sie nicht, die DB_PW-Variable vollständig aus der Dockerfile-Datei zu entfernen. Docker-compose stellt sicher, dass die Variable in den ausgeführten Container übergeben wird, aber sie ist nicht im Image selbst vorhanden.
Um das Projekt auszuführen, müssen Sie nun sicherstellen, dass der Projektmappensordner „docker-compose“ als Startprojekt eingerichtet ist. Beachten Sie, dass die Schaltfläche „Debuggen“ auf „Docker Compose“ festgelegt ist. Um zu sehen, wie sich die Magie entfaltet, legen Sie im Startcode dort einen Breakpoint fest, wo der Code die Verbindungszeichenfolge aufbaut, und debuggen Sie die App dann. Sie sollten sehen, dass Configuration["DB_PW"] in der Tat in der Lage ist, den von docker-compose übergebenen Wert zu ermitteln.
Verschieben des Geheimniswerts aus Docker-Compose
Aber meine Geheimnisse sind noch immer in der docker-compose-Datei enthalten, und Sie wissen und ich weiß, dass ich diese Informationen irgendwann versehentlich in meine öffentliche Quellcodeverwaltung pushen werde. Docker-compose wird auf meinem Computer und nicht in einem Docker-Image ausgeführt. Dies bedeutet, dass docker-compose auf Informationen auf dem Host zugreifen kann. Ich könnte eine Umgebungsvariable auf meinem Entwicklungscomputer erstellen, um das Kennwort zu speichern und durch docker-compose ermitteln zu lassen. Sie können sogar temporäre Umgebungsvariablen in der Paket-Manager-Konsole von Visual Studio erstellen. Aber Docker bietet mit seiner Unterstützung für das Lesen von ENV-Dateien eine noch bessere Option.
Standardmäßig liest docker-compose eine Datei namens „.env“. Es gibt keine Basis für den Dateinamen, er lautet einfach „.env“. Es ist auch möglich, .env-Dateien zu benennen und in docker-compose die env_file-Zuordnung zu verwenden, um sie in der Dienstbeschreibung anzugeben. Weitere Informationen zu benannten .env-Dateien finden Sie in meinem Blogbeitrag unter bit.ly/2CR40x3.
Sie können diese verwenden, um Variablen zu speichern, z.B Verbindungszeichenfolgen, etwa „dev.env“, „test.env“ oder „production.env“, oder für Geheimnisse nutzen. Als ich die Tools zum Hinzufügen der Containerorchestrierung verwendet habe, hat die docker.ignore-Datei, die die Tools erstellt haben, .env-Dateien aufgelistet, damit diese nicht versehentlich in Ihre Quellcodeverwaltung gepusht werden.
Visual Studio lässt das Hinzufügen einer Datei zum docker-compose-Projekt nicht zu, also habe ich dieses Problem umgangen, indem ich die neue Textdatei dem Ordner „Solution Items“ hinzugefügt und diesen dann in das docker-compose-Projekt verschoben habe.
Ich speichere mein Geheimnis in der .env-Datei. Dies ist der Inhalt der Datei:
DB_PW=eiluj
Abbildung 3 zeigt, wie meine endgültige Projektmappe aussieht.
.png "Die endgültige Projektmappe einschließlich der neuen .env-Datei")
Abbildung 3: Die endgültige Projektmappe einschließlich der neuen .env-Datei
Auf diese Weise kann ich einfach das Kennwort festlegen, während ich die App entwickle und debugge, und muss keine Angst davor haben, dass es in Dateien enthalten ist, die ich möglicherweise freigebe. Darüber hinaus habe ich Optionen, andere Variablenkonfigurationsinformationen bereitzustellen.
Meine Geheimnis ist auch weiterhin Nur-Text, was aber auf meinem Computer in Ordnung ist. Sie werden solche Geheimnisse jedoch in der Produktion wahrscheinlich verschlüsseln wollen. Elton Stoneman gibt dazu in seinem Buch „Docker on Windows, Second Edition“ (Packt Publishing, Februar 2019) Hinweise.
Nächste Schritte
Ein naheliegender nächster Schritt für mich wäre, den Container bereitzustellen und herauszufinden, wie ich die Umgebungsvariable mit dem Kennwort für meine Azure SQL-Datenbank in eine Containerinstanz bekomme. Diese Herausforderung hat viel Recherche und Experimentieren erfordert, und da in dieser Kolumne der Platz nicht ausreicht, habe ich unter bit.ly/2FHdbAM einen Blogbeitrag zur vollständigen Implementierung dieses Schritts verfasst. Ich habe für den Docker-Blog auch über das Veröffentlichen in Docker und das Hosten in einem virtuellen Azure-Computer geschrieben. Ich werde die Onlineversion dieses Artikels mit der URL für diesen Blogbeitrag aktualisieren, sobald sie verfügbar ist.
Der Plan für die nächste Ausgabe dieser mehrteiligen Kolumne ist der Übergang von Azure SQL-Datenbank zu einer SQL Server-Datenbank in einem eigenen Container. Dabei wird das bisher Gelernte über Docker mit Lektionen aus einer früheren Kolumne („On-the-Fly SQL Server with Docker“ (Schnelle SQL-Server mit Docker) unter msdn.com/magazine/mt784660) kombiniert. Die beiden Blogbeiträge, auf die ich verwiesen habe, behandeln die Veröffentlichung der Images und das Ausführen der Container in der Cloud.
Julie Lerman ist Microsoft Regional Director, Microsoft MVP, Coach für das Softwareteam und Unternehmensberaterin. Sie lebt in den Bergen von Vermont. Sie hält bei User Groups und Konferenzen in der ganzen Welt Vorträge zum Thema Datenzugriff und zu anderen Themen. Julie Lerman führt unter thedatafarm.com/blog einen Blog. Sie ist die Autorin von „Programming Entity Framework“ sowie der Ausgaben „Code First“ und „DbContext“ (alle bei O’Reilly Media erschienen). Folgen Sie ihr auf Twitter: @julielerman, und sehen Sie sich ihre Pluralsight-Kurse unter bit.ly/PS-Julie an.
Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Steven Green und Mike Morton (Microsoft), Elton Stoneman (Docker)
Elton Stoneman ist ein Pluralsight-Autor, Microsoft MVP und Developer Advocate bei Docker. Seit dem Jahr 2000 hat er mit Microsoft-Technologien erfolgreich Lösungen konzipiert und bereitgestellt, zuletzt Big Data- und API-Implementierungen in Azure, sowie verteilte Anwendungen mit Docker.
Zurzeit interessiert er sich für die Entwicklung des Microsoft-Stapels und untersucht die großartigen Möglichkeiten, vorhandene .NET Framework-Apps mit Docker zu modernisieren und neben neuen .NET Core-Apps in Windows- und Linux-Containern auszuführen.
Er ist regelmäßiger Referent und Workshopleiter bei Konferenzen. Er hat erfolgreich als Referent an DockerCon, NDC, DevSum, ProgNet, SSD, Container Camp und Future Decoded teilgenommen. Er ist auch häufig Gast bei Benutzergruppen: Docker London, London DevOps und WinOps sind seine „Heimspiele“.