[QUESTION] Please, answer +1 if the solution is working properly for you (Through VS2017 or CLI environment)

[CESARDELATORRE]

A small favor, can you answer +1 to this thread if the solution is working for you (Through VS2017 or CLI environment)? - Bits compilation-Deploy-Run in Docker.
We'd like to know if the environment/solution is working for most of the people or not.

Better if you specify what environment you are using, like answering any of the following:

+1 (VS2017)
+1 (CLI)
+1 (Both)

Answer with a -1 if you have issues and you couldn't make it work (compile/deploy/run to Docker), any of the following:

-1 (VS2017)
-1 (CLI)
-1 (Both)

We could create a survey, but we're not looking for specific statistics jus a sense of how it is working for the majority, and this way based on issues might be quicker for you guys than going to surveymonkey or anything like that.

Thank you! :)

[kifjj]

+1 (Windows CLI, on Win10 Entr, RAM 7GB, got a lot of problems with SQL Container, managed to make it work after assigning docker 4352 MB and freeing RAM) ... wondering what HW is required to develop seriously with containers in real world scenarios. Any points?

[CESARDELATORRE]

@kifjj That's why we mentioned to set at least 4096 MB of memory to Docker and recommend a 16GB ram machine in the setup instructions. Take into account that this is only because SQL Server container requirements in a dev or testing environment where you spin everything up as containers. In a real production environment it is recommended to take out the DBs from Docker and put your Databases in a High Available system like Azure SQL DBA or a SQL Server cluster, on-premises. So the memory you'd need for that would be less.
Your microservices using .NET Core need very small amounts of memory, so you can have many and that won't be, usually, the issue in dev-test environments.
For a development/testing Docker environment, a 16GB machine would be good for most of the scenarios. It depends on how many "infrastructure containers" (like SQL, Redis and others) you have included. But usually, 16GB would be good to go for most dev/test environments.
For production, it really depends how scalable you'll need your system to be. When using an orchestrator (not just Docker) like Docker Swarm, Kubernetes, Meals DCOS in Azure Container Service or using Azure Service Fabric, it will depend on how many instances per microservice-type you want to have for high scalability. Not just memory but number of VMs, as well.
In short, HW requirements? it really depends on how large is your application in regards infrastructure (that impacts dev/test) and how scalable you want it to be in production

[CESARDELATORRE]

+1 (Both environments, CLI & VS2017) - Windows 10 Enterprise, RAM 16GB. Testing on Multiple machines.
:)

[HarshaRaikar]

Hi CESAR

I am getting timeout error when the MVC application first starts.
At: CatalogService.cs line 54.
dataString = await _apiClient.GetStringAsync(catalogUrl);

VS2017, windows 10 , 16GB RAM

[HarshaRaikar]

Oops. It was docker memory i guess. I set it to 4096MB and it started working now. :)

[dsrodenas]

+1 (VS2017) - Windows 10 Enterprise, RAM 16GB

[harrchen]

I tried to install the solution to Server 2016 with VS2017 without success. There doesn't seem to be a suitable docker installation for Windows 2016. I tried to install docker via powershell but cannot find a way to perform necessary configuration as outlined in this document. The reason I want to use Windows 2016 is that I cannot create a windows 10 image in my azure subscription.

[harrchen]

Also just realized that docker for windows will not work for Azure VMs. As such, is there a way to have the eShop sample app setup and running in Azure?

[kifjj]

@CESARDELATORRE thanks for your explanation. Everything makes sense, just a point I am missing.
Since in prod SQL Srv will not be in a container (which makes total sense) wouldn't be better to keep it out even in dev?

[eiximenis]

Hi @kifjj
One reason for using SQL Server in a container is for helping with managing external dependencies in development. We are not using only SQL Server but also Redis (in the Basket microservice), and RabbitMQ for microservice-to-microservice communication (still not in master branch but merged soon).
Forcing everyone to install and configure all these external dependencies would prevent most people to run the application. By using all these dependencies in Docker container you only need to pull the repo, build the images and everything is working fine.
Of course you can use SQL Server standalone: just update docker-compose files and everything should be fine :)

Thanks!

[CESARDELATORRE]

@kifjj @eiximenis Reasons given by eiximenis (Eduard) plus:
When using databases on containers that are spin-up and populated with the same sample data, that makes a perfect scenario for Integration-Tests, as the tests are predictable based on the same set of data.
However, you can of course have your databases on any regular SQL Server on-premises or Azure SQL DB. You'll just need to create the DB, change the connection-strings, and you're done. Even the sample data can be populated to those databases, too., as we do that with EF code.

One more point, you cannot use VMs in Azure for a DEVELOPMENT environment with "Docker for Windows" that would need a nested VM in Hyper-V, and that is not supported in Azure. However, you could, of course, deploy the containers to an Azure Linux VM that would be a Docker Linux host, for testing/production environment, but not development with Visual Studio, etc..

[mktitan]

+1 VS17. Looks great.