I'm using Azure DevOps, and have a Linux build pipeline (ubuntu-16.04) setup that builds the code, starts containers with Docker Compose, then runs integration tests using the containers. This all works great.
Now I want to setup a Windows build pipline that does the same thing. However, with both the windows-2019 and win-1803 images, when I do docker stack up, I get this error message:
image operating system "linux" cannot be used on this platform
So, I guess Docker is installed in Windows mode, and thought to switch it to Linux containers using:
DockerCli.exe" -SwitchLinuxEngine
or
"%ProgramFiles%\Docker\Docker\DockerCli.exe" -SwitchLinuxEngine
However, the DockerCli.exe executable doesn't seem to be installed at all.
The only 2 things I can think of are:
Setup a self-hosted build agent
Somehow start the required containers somewhere else
But both of these will be a lot of work to setup, which I really don't need, neither do I want the running costs, or the job of maintaining it.
Are there any workarounds to run Linux containers on hosted Windows build agents?
Run Linux containers in an Azure DevOps Windows hosted build agent
Firstly, see the images listed which installed on Windows hosted agent: Docker images in Windows hosted agent. Docker EE on Server does not support Linux containers at all. So, it is impossible to build Linux docker image on Hosted Win-1803 agent. It can only build Windows docker image.
Until now, the only two workarounds is using self-hosted agent which based on Windows machine, or run a build which has two separate agent jobs(Pass the build artifacts back and forth between one agent job which run on Hosted Linux agent and the other is running on Hosted Windows agent) .
But since these two workarounds are all not convenient for you, there will not any other work around can achieve what you want.
In addition, there has a such suggestion feature raised on our official forum: Support for Docker with Linux Containers on Windows (LCOW) on hosted agent pool . You could vote and comment there, our Product Group team will review these suggestions regularly and consider taking it as Developer Roadmap. If this feature can be true, I think it will be very convenient to build Linux Container and without considering about which agent can only support.
Related
I have a Windows Server 2019 (v1809) machine with Kubernetes (bundled with Docker Desktop for Windows). I want to enable Vertical Pod Autoscaling for the cluster I have created.
However, all the documentation I can find is either for a cloud service or a Linux-based system. Is it possible to implement VPA for the Docker Desktop Kubernetes in Windows or Minikube?
While VPA itself is a daemon, the pods it controls are just API objects as far it knows and can be anything on any platform. As for compiling a VPA container for Windows, I wouldn't expect any problems, you'll just need to build it yourself since we don't provide one.
I am unable to run linux containers as I run Docker in my development vm which has visual studio installed and I have not been ablt to get it working yet as it is an unsupported scenario and many of the google solutions have unfortunately not resolved it for me.
However, I was thinking that maybe I could keep Docker Desktop running on my dev vm (so that VS would be happy it was still "local") but actually have the Docker engine/daemon bit running on a remote host where linux containers actually work - is it possible to repoint Docker Desktop for Windows to a Docker engine on a remote host?
Apologies if my terminology is rubbish, I am new to Docker. Also, I have done some searching and have seen articles and messages talking about docker machine and DOCKER_HOST environment variables, but I cannot see anything yet that applies to Docker Desktop (e.g. I don't have that env variable set on my docker windows vm so maybe it doesn't use that mechanism).
Thanks in advance
I just started messing with containers and managing them. Then I came across with Kubernetes. I've already installed Docker and tried out a few examples. But when it came to managing them with Kubernetes, I've kinda stuck.
I've found out that I can run Kubernetes with minikube on Windows on my laptop for development. But I want to know if I can run Kubernetes on my production server or local development environment because as they point out minikube doesn't have all featues that Kubernetes can offer. So in production I guess I can't use minikube, right?
Because of the data that I'm using I can't use Google cloud or Azure for production, laws forbid that. So in short do I have to switch to cloud to use Kubernetes or can I use it in my Windows Server machine without any cloud environment?
I've already read How to do local development with Kubernetes? question but they've also recommended minikube.
Thanks for your answers.
So in production I guess I can't use minikube, right?
Not really advisable, minikube is ment to support learning/local single machine dev tasks.
do I have to switch to cloud to use Kubernetes or can I use it in my Windows Server machine without any cloud environment?
IMHO Windows and kubernetes are not really there yet. If you don't want to install dedicated linux box or switch to cloud there is always option to run it from within virtualized environment (VirtualBox, VMWare...). Maybe not super optimal performance-wise (additional layers of virtualization added on top of windows) but can be sufficiently stable for production (depends on available hardware and resources requirements).
So far I have been using Travis and was quite happy about it (although it only provides Linux environments) however I am considering to give TeamCity a try and work with YouTrack as well. My current scenario is the following:
I have a project that consists of multiple applications and libraries that should are platform independant targeting Windows, macOS and Linux and bundled together for each of those platforms. Everytime I finish a feature branch and merge it to the development branch I need to manually pull the new changes, compile and run test suites on Windows and macOS separately.
I'd like to be able to push changes to the development branch and have the CI tool handle all platforms simultaneously. Therefore I noticed that I can setup an online TeamCity server (for example on DigitalOcean) and have a Linux build agent running besides it while having a Windows build agent on my local desktop computer and a macOS build agent on my (local) Macbook in order to let those machines use the local toolchains native to their systems.
First of all I'd like to know whether this is a feasible setup in general. I considered using Docker images of build agents until I noticed that a Windows build agent only runs on Windows servers and I'd have to configure the container myself with installing msbuild and such. Therefore I considered just using my local machines with their already setup toolchains as build slaves in this case.
Finally, I'd like to know whether TeamCity provides build queues or something similiar. What I am referring to is the following situation: I am on the train and finishing something on my Macbook and merge it into the branch. However my desktop with the Windows build agent is offline at the moment. Does it work through the queued commits/builds once I boot it up again?
Everything in your scenario seems feasible to accomplish with teamcity. You could have a set up with 3 builds all with the same trigger. Each build would have the build steps for a specific operating system. If you had all machines and agents running they would likely all be triggered at the same time and perform their builds in parallel.
I"m not sure what you are trying to say in paragraph 4 about the "windows build agents only runs on windows servers". Windows build agents can run on desktop versions on windows such as windows 7 or windows 10.
Yes, teamcity has a queue. If an agent is offline the build will be held in the queue until the agent is back online or the build is cancelled.
I have a hard time finding information about this. Somewhere I've seen news that Docker has now natively been integrated to Windows. So apparently this means they are not "Linux container" but some kind of "Windows containers"? Does anyone have more information on this?
There has been a significant update thanks to many Docker acquisitions, such as Unikernel. Now it is possible to install beta (as of April '16) of Windows program running Docker without any hassle.
Faster and more reliable: no more VirtualBox! The Docker engine is running in an Alpine Linux distribution on top of an xhyve Virtual Machine on Mac OS X or on a Hyper-V VM on Windows, and that VM is managed by the Docker application.
UPDATE (September '17)
Full native support available here.
An integrated, easy-to-deploy development environment for building, debugging and testing Docker apps on a Windows PC. Docker for Windows is a native Windows app deeply integrated with Hyper-V virtualization, networking and file system, making it the fastest and most reliable Docker environment for Windows.
Microsoft has added containerization primitives to the Windows kernel and are helping porting Docker Engine to Windows. That means you can run native Windows containers with Docker on Windows Server 2016. It's been in tech preview for a while and is free to try. Details here: https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/manage_docker?f=255&MSPPError=-2147217396
I have read this:
https://azure.microsoft.com/blog/2015/04/16/docker-client-for-windows-is-now-available/
As you can read there is only interface to manage docker containers inside Linux so far.
Currently (October 2016) there're a mess here.
Windows Server 2016 and Windows 10 build 1607 (Anniversary Update) support Docker containers natively. Obviously only with Windows as base images. Moreover only with Windows Server 2016 (Nano or Core).
But there's also Docker for Windows - which is the only suggested option on https://www.docker.com/products/docker#/windows. It's easily can be thought that that Docker is the one which runs natively on Windows. But it isn't!
Docker for Windows uses a VM with Linux to host all containers. So you can't pull Windows images.
So a try to pull an image will fail with "unknown blog" error:
C:\>docker pull microsoft/nanoserver
Using default tag: latest
latest: Pulling from microsoft/nanoserver
5496abde368a: Retrying in 1 second
94b4ce7ac4c7: Downloading
unknown blob
So Docker for Windows can be used only for Linux images!
How f... it's obvious, right?
For "real native Docker" (to run Windows container) we currently have download and install it manually as described in this manual - https://msdn.microsoft.com/virtualization/windowscontainers/quick_start/quick_start_windows_10