Updated 04. Setting eShopOnContainer solution up in a Mac, VS for Mac or with CLI environment (dotnet CLI, Docker CLI and VS Code) (markdown)
Cesar De la Torre
parent
05e91a7b81
commit
82a6f4dbd2
@ -98,6 +98,20 @@ And by typing `docker ps` you can see the containers running in Docker. The infr
|
||||
|
||||
# Option B: Use a CLI environment (dotnet CLI, Docker CLI with the bash shell) and VS Code as plain editor
|
||||
|
||||
As a summary, with the following simple CLI commands in a bash window you'll be able to build the Docker images and deploy the containers into your local Docker host:
|
||||
|
||||
```
|
||||
$ git clone https://github.com/dotnet-architecture/eShopOnContainers.git
|
||||
$ cd eShopOnContainers
|
||||
$ docker-compose build
|
||||
$ docker-compose up
|
||||
```
|
||||
|
||||
The `docker-compose build` is in reality optional because if you run the `docker-compose up` command and you don't have the Docker images built, Docker will run the `docker-compose build` under the covers.
|
||||
But splitting the commands in two makes it clearer for you to know what it is doing.
|
||||
|
||||
The following explanations show you in detail how you should set it up, build and deploy.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. [Docker for Mac](https://docs.docker.com/docker-for-mac/install/). You should already have this.
|
||||
@ -106,9 +120,9 @@ And by typing `docker ps` you can see the containers running in Docker. The infr
|
||||
1. (OPTIONAL) Bower ($ sudo npm install -g bower) needed by the MVC web app.
|
||||
1. [.NET Core and SDK](http://dot.net). Install the SDK and runtime.
|
||||
|
||||
### Local installation of NPM/Node, Bower and .NET Core SDK are not required when using Docker Multi-Stage
|
||||
### (OPTIONAL) Installation of NPM/Node, Bower and .NET Core SDK on the local Mac is not required when using Docker Multi-Stage
|
||||
|
||||
The SDKs and dependencies like NPM, Bower and even .NET Core SDK are optional because when building through Docker Multi-Stage it will be using the dependencies available within the ASP.NET Core build image, not the installed software on the local machine/PC.
|
||||
The SDKs and dependencies like NPM, Bower and even .NET Core SDK are optional because when building through Docker Multi-Stage it will be using the dependencies available within the ASP.NET Core build image container instead of the installed software on the local machine/Mac.
|
||||
However, if you will be developing .NET apps in the Mac or customizing eShopOnContainers, it is recommended to install all the dependencies locally, as well.
|
||||
|
||||
# Compile the application's projects and build the Docker images with a single command thanks to Docker Multi-Stage
|
||||
@ -144,61 +158,25 @@ With a single command you can deploy the whole solution into your local Docker h
|
||||
|
||||
`docker-compose up`
|
||||
|
||||
<img src="img/cli-windows/docker-compose-up-1.png">
|
||||
|
||||
|
||||
Note that the first time you try to run the application (with docker run or docker-compose) it detects that it needs a few related infrastructure images, like the SQL Server image, Redis image, RabbitMQ image, etc. so it will pull or download those base images from the Internet, from the public repo at the Docker registry named DOCKER HUB, by pulling the "microsoft/mssql-server-linux" which is the base image for the SQL Server for Linux on containers, and the "library/redis" which is the base Redis image, and so on. Therefore, the first time you run "docker-compose up" it might take a few minutes pulling those images before it spins up your custom containers.
|
||||
|
||||
Finally, you can see how the scripts waits after deploying all the containers:
|
||||
|
||||
<img src="img/cli-windows/docker-compose-up-1.2.png">
|
||||
|
||||
|
||||
- The next time you run "docker-compose up" again, because you already have all the base images downloaded and registered in your local repo and your custom images built and ready to go, it'll be much faster since it just needs to deploy the containers, like the following screenshot:
|
||||
|
||||
<img src="img/cli-windows/docker-compose-up-2.png">
|
||||
- The next time you run "docker-compose up" again, because you already have all the base images downloaded and registered in your local repo and your custom images built and ready to go, it'll be much faster since it just needs to deploy the containers.
|
||||
|
||||
- <b>Check out the containers running in your Docker host</b>: Once docker-compose up finishes, you will have the original bash window busy and showing the execution's output in a "wait state", so in order to ask to Docker about "how it went" and see what containers are running, you need to open a second bash window and type "docker ps" so you'll see all the running containers, as shown in the following screenshot.
|
||||
|
||||
|
||||
Type `docker ps`
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## B.1 - Building the application from a Docker Linux "build container"
|
||||
|
||||
Option B.1 is the recommended way to build your binaries before creating the Docker images as you'd be using the same Linux build-container with the SDKs that you can also use for your CI/CD pipelines in your DevOps system (that is VSTS, TFS, Jenkins, etc.).
|
||||
However, take into account the note below if you have that issue.
|
||||
|
||||
---
|
||||
|
||||
*IMPORTANT NOTE (as of Oct. 2017):*
|
||||
|
||||
This is the simplest way to do it from the CLI, and with the latest tests using the Docker build-container image with SDKs, microsoft/aspnetcore-build:2.0.2 we're not getting this issue, any more.
|
||||
|
||||
But if you get the following error when compiling from the Linux build-container:
|
||||
|
||||
`MSBUILD : error MSB4017: The build stopped unexpectedly because of an unexpected logger failure.`
|
||||
`ci-build_1 | Microsoft.Build.Exceptions.InternalLoggerException: The build stopped unexpectedly because of an unexpected logger failure. ---> System.IO.IOException: The process cannot access the file because it is being used by another process.`
|
||||
|
||||
That is a [bug in .NET CLI when running "dotnet publish" within a container](https://github.com/Microsoft/msbuild/issues/2153#issuecomment-305375162).
|
||||
|
||||
If you get this issue, until the fix is released by the dotnet CLI team in the next version of the .NET CLI, in the meantime, follow the OPTION B.2 explained below, which is building the app's .NET binaries in the local Mac, instead of from a Linux build-container.
|
||||
|
||||
---
|
||||
|
||||
### Simplest and recommended CLI approach in a Mac machine (or Linux machine)
|
||||
|
||||
Open a bash shell and run the following four commands:
|
||||
|
||||
```
|
||||
$ git clone https://github.com/dotnet-architecture/eShopOnContainers.git
|
||||
$ cd eShopOnContainers
|
||||
$ docker-compose -f docker-compose.ci.build.yml up
|
||||
$ docker-compose up
|
||||
```
|
||||
|
||||
The first two commands clone the git repository onto your machine, and changes the current directory to the root directory of the project.
|
||||
|
||||
The third command, `docker-compose -f docker-compose.ci.build.yml up` creates a Docker container based on an image used for Continuous Integration (CI) builds. That image has all the required SDKs and tools loaded on it. These include .NET Core, the .NET Core CLI and SDK, npm, and required npm packages. Once the container starts, it will mount your source directory as a shared drive, then build and publish all the projects that make up the eShopOnContainers application.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user