I see that there is now an effort to make Mesos available on Windows (servers at least).
https://mesosphere.com/blog/2015/08/20/mesos-everywhere-apache-mesos-for-windows-server/
Does anyone know of updates/roadmap on this effort? I tried looking in https://github.com/apache/mesos/search?q=&type=Issues but don't see any issues for Windows support.
Mesos uses JIRA to track issues, that's why nothing shows up in GitHub. The Windows port is now very actively being worked on. There are two JIRA epics that track the effort:
Introduce CMake as an alternative build system.
Mesos on Windows
The plan is to first port the Mesos Agent. Once it's done, it will become possible to have a cluster with Master(s) running on Linux and Agents running on either Linux or Windows (or both).
The current implementation of CMake-based build system is pretty functional. It allows to rope in all the dependencies for building the Agent as well as produces the Agent binary. The work on porting Mesos build system tooling (post-reviews script, bootstrap script, etc.) is currently under way.
You could check out this thread http://search-hadoop.com/m/0Vlr6bGrJMIwE1j Alex reply his plan in this thread.
Related
I have been developing and maintaining some windows on windows Docker containers that run ASP.NET core applications on Windows 2016 (using Docker EE) for some time now. I was planning on turning over all ongoing updates/maintenance to server administrators, but I have hit a problem. When I started I believe I was using SAC builds, but now none of the SAC (or LTS for that matter) builds pull on Windows 2016, and though I have spent a good deal of time googling, this whole thing seems to be a big cluster. With docker on Linux, I would just use any LTS distro and apply updates when building the container. Does Microsoft have a clear plan on doing the same? It seems like they are missing the point of docker. I want to run a windows on windows container in windows server 2016, and I want to make sure when I recreate it that I am getting the latest security updates.
https://devblogs.microsoft.com/dotnet/net-core-container-images-now-published-to-microsoft-container-registry/
This page talks about the big changes made in Docker images recently and specifically says the following:
.NET Core images for Nano Server 2016 are still available on Docker Hub and MCR and will not be deleted. You can continue to use them but they are not supported and will not get new updates. If you need to do this and previously used manifest tags, like 1.1-sdk, you can now use the following MCR tags (Docker Hub variants are similar)
Does this mean the new tags listed get updates? I would assume they would tag it with LTS instead of SAC2016 to better convey the notion that they are continuing to update.
This page seems to be really helpful, but none of the images listed pull on windows server 2016:
https://andrewlock.net/exploring-the-net-core-mcr-docker-files-runtime-vs-aspnet-vs-sdk/
This is what I get when I attempt to pull any of the images:
1709: Pulling from windows/nanoserver
no matching manifest for unknown in the manifest list entries
To clarify, I can currently run all my applications using such images as these:
mcr.microsoft.com/dotnet/core/runtime 2.2-nanoserver-sac2016 4a3bbafea836 3 months ago 1.27GB
mcr.microsoft.com/dotnet/core/sdk 2.2-nanoserver-sac2016 9773d80bdd64 3 months ago 2.62GB
I am looking for clarity on support of these images, or a clearer direction to migrate.
Right now, for LTS, the image you want to pull is: mcr.microsoft.com/dotnet/core/aspnet:2.1. Since 2.1 is the LTS release of ASP.NET Core. The underlying server reference doesn't matter, honestly, and all the .NET Core images are multi-arch, so the right underlying images are pulled automatically (linux for linux host, Windows for Windows host, and AMD64, x86, ARM, etc.).
The OS of the image (aside from being the right architecture and platform) is really kind of meaningless. It's mostly a translation layer. Images aren't VMs, the OS is on the host, and that's where your security patches and such apply. As long as your host is patched up, you're good.
UPDATE
This has apparently led to some pedantic arguments in the comments, so let me be a little more clear. What I'm talking about here is best described via this graphic from the Docker site:
Whereas a VM has a copy of the OS on each instance, containers utilize a shared host OS. The OS base image is basically a proxy. It provides the API, but everything at an OS-level happens on the host OS, not in the container.
As such, yes, the OS base image matters to a certain extent. You can't target a Linux base image and deploy to Windows Server. You'd have issues targeting Windows Server 2019 and deploying to 2016, as well. However, assuming that the OS base image is remotely compatible with the host OS, then everything above and beyond that is meaningless.
Specifically to the discussion of patches and LTS versions, you don't need to care, because again, what's actually running is components of the host OS, not anything from the image itself. You can actually see this if you open Task Manager on the host OS. You'll see duplicate system-level processes tied to each running container. Even though the container shows running processes as well, it is these host-level processes that are actually doing the work, and therefore, it is only important that they are patched and supported. If everything is good on your host, you need not worry about the containers, at least for the OS part of things.
https://github.com/docker/for-win/issues/3761
I was working around Mar 12 when all the docker pulls stopped working because of the changes MS did. So I am sure I saw this page before, but on rereading the entire thing again, I see this comment:
docker pull mcr.microsoft.com/windows/servercore:ltsc2016
That seems like a reasonable tag name for long term support. Lo and behold it works. I am currently theorizing that nanoserver is only for the latest and greatest, and am thinking of opening an issue on github to see if someone will answer that definitively.
I think one of the comments on that page from the github maintainer settles the debate in the Chris Pratt's answer. I think mis-information floating around about security is dangerous, so I am reposting here to help future souls who stumble on this question:
Yes, when running with process-isolation, the version must match the Windows kernel version you're running on. Unlike Linux, the Windows kernel does not have a stable API, so container images running on Windows must have libraries that match the kernel on which they will be running to make it work (which is also why those images are a lot bigger than Linux images).
Vulnerable libraries in a docker container DO matter. You cannot rely on the host OS being up to date to protect you.
Further Research
Still researching this, so adding my updates for your benefit as I find them:
Article about Migrating
https://www.altaro.com/hyper-v/nano-server-no-longer-supported-for-infrastructure/
TLDR - Move to servercore
Server 2016 14393 Tags on Docker Hub
The main docker hub nano server page does not list any 14393 tags, but visiting the full tags list at the bottom of the page shows many. I was able to pull mcr.microsoft.com/windows/nanoserver:10.0.14393.1066 and it is only 1GB instead of 14GB for server core
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'm looking on ways to deploy a ruby on rails 4 app built on windows 7 box. I'm looking to use Heroku at the moment.
Can you please provide any pointers regarding heroku or any other easier and cheaper deployment options available out there..
Any issues That I may face due to the difference in OS in the dev environment (windows) and the deployment environment (linux on heroku)?
This is my first professional app, so any pointers will be helpful for now and also for future applications that I may work on.
Also what is the more preferred OS for ruby on rails development ?
Thanks in Advance!
You probably won't face any issues with deployment on Heroku. Heroku is the easiest option out there (albeit one of the priciest once you're off the free tier)
What's more likely to happen on Windows is that you'll find it hard to build certain gems for development, and cutting edge releases will probably not work well.
Much better to pick up a Linux distro for this.
You can also check out bluemix , which is also free for small projects. I know Heroku is not particularly windows friendly, not sure if bluemix is any better in that reguard, but it is extremely easy to deploy to.
Heroku has set of tools called heroku toolbelt, that makes easy to deploy apps to heroku. you can download heroku tool belt for windows from here
Generally you should be able to port any rails app you develop in windows to Linux/Mac, how ever since the ruby/rails community is largely built around Linux/Mac, responses/options to your issues regarding the rails apps will be low. and there are some gems which doesn't work on windows at all. So its best to move to either Mac/Linux if you are planing to continue on rails.
Once you come to Linux/mac world there are lots of providers much cheaper than heroku like DigitelOcean, however heroku would be the easiest for a beginner I believe.
HTH
One strategy you could try is to do the following:
Set up a VirtualBox or VMWare VM running Linux (Ubuntu would be a good candidate if you are not used to Linux).
Get your project into the VM and get the bundle install and everything working in Linux, you will probably find you need to make some changes in your Gemfile if you have anything windows specific there.
Install the Heroku tool-belt on the Linux VM and install to Heroku from there.
Taking the Windows / Linux transition pain on your local machine will make it much easier than Windows direct to Heroku.
I need to do a installation of windows updates (OS and Microsoft Security Essentials) on multiple clients using Cent-OS Server. I'm not very familiar with Linux systems and I cant find an appropriate tutorial On the internet.
Give OPSI a try, this is an OpenSource Deployment Solution which works on CentOS:
http://www.opsi.org/
This is an integrated system to deploy full installation as well as simple updates or rollouts.
yum installs RedHat/CentOS/Fedora RPM packages on RedHat/CentOS/Fedora systems. It doesn't have anything to do with Windows. It doesn't understand exe files or anything like that.
I'm not even sure where to begin to understand what the question you are actually trying to ask is... unless your question is really just as confused as it sounds and you are failing to understand the difference between package managed linux systems and Windows systems.
I have had basic tests for meteor on a Windows7 PC.
But there the application crashed too often.
Before this, I tested meteor on PC running Windows8. There, crashes happened much less often and generally they were recovered when I shutdown and rebooted the meteor.
Is Meteor unstable on windows7?
Or is there any way to avoid this?
The version packaged to the MSI installer that can be found on win.meteor.com is not official. If you want a more stable, try the virtualized option I've described on the site. I've been using that for a month without issues.
Please could you be specific about what problems you are seeing, for example, what do you mean by 'crash'.
You can certainly raise issues on SO, but if they appear to be specific to the windows port, please raise a ticket at: https://github.com/sdarnell/meteor
The only difference between Win7 and Win8 meteor, is that the installer sets the Win7 compatibility mode for the node.exe executable on Windows 8.
There are also relatively few differences between the windows port of meteor and the official linux/mac release. So there is a possibility that the issue is either environmental (e.g. you have different things installed on the two machines), or it may even be a core issue that just happens to appear more often Win7 due to timing issues (there was a case of this in 0.6.3).