We are currently using multiple self-hosted build agents with Windows 10 as the operating system. In various pipelines in Azure Devops (whether Online or OnPremis), we have not had any bad experiences or questioned the OS we chose over the many years.
Now IT approached me and asked if there was anything wrong with using Windows Server 2019/2022 as the OS for a self-hosted build agent. I guess in the long run it would be a price advantage.
But are there any other advantages or disadvantages between Windows Server 2019/2022 and Windows 10/11?
There are no other advantages or disadvantages between Windows Server 2019/2022 and Windows 10/11. Only cost... and maybe system requirements of your build/external components.
Related
Can I install Visual Studio Code on Windows server 2008 ?
I am a developer but I sent the information to my administrators and they told me that the setup file crashes after launched
I get seput file from hee https://code.visualstudio.com/download
procesor: Intel(R) Xeon(R) Gold 6142 CPU # 2.60Ghz - 2.59 GHz
RAM: 8 GB
64-bit
virtual machine
1 CPU - 2 cores
Windows Server 2008
First time answering here so bare with my vintage reply formatting. (also pardon that i couldn't capture screen due to server is on a intranet that not accessible on this device causing a long reply)
Being a unfortunate fellow that need to work on legacy Systems and Application frequently, i happen to have a fresh 2008R2 server recently setup by my team's Server Admin with following specs:
processor: Intel(R) Xeon(R) Gold 5220 CPU # 2.20Ghz - 2.19 GHz ,
OS: Windows Server 2008R2 x64 ,
RAM: 8GB
The versions that is able to install was 1.70.3,which is the same version that is the last supporting versions for Windows 7 as well,if you happen to need to work on devices using that OS version.
although i'm uncertain whether it is a VM or not, i'd like to point out a few more things that your question did not cover but need to consider:
The installer version (System setup vs User Setup)
aside from the x64 |x86 | ARM installer differences, as you've not mentioned which versions of the build and which exact setup installer you sent to your admin, i've first replied which build version successfully installed on 2008R2, which as of writing the latest build was 1.73.0 and on run,it pop up a error message as follow regardless of System/User Setup:
This Program does not support the version of windows your computer is running.
in our current case that we want specific previous versions installer, VScode FAQ on previous versions have a URL lists that enables you to download a specific build version of your preferred setup. For my case (and also refer below to exactly why this one), i've go for System setup, and i know the aprox. supporting version was ~1.70.0, so i used the link as below and replace the {version} to start:
https://update.code.visualstudio.com/{version}/win32-x64/stable
Active Domain, Multiple user sessions etc.
Per VSCode requirements page stated,
VS Code does not support multiple simultaneous users using the software on the same machine, including shared virtual desktop
infrastructure machines or a pooled Windows/Linux Virtual Desktop host
pool.
as im not sure do you work solo or do have fellow colleagues to code on the server at the same time, you might need to reconsider to install using user or System setup.
if your intentions are to use exclusively on a specific AD account, then user setup should probably be good enough.
however, if the intentions was to setup say a shared Remote desktop connections on the VM that allows multiple RDC sessions simultaneously for coding,programming etc., so you intend to install a system setup to allow all users on said server to be able to use VScode, then you might run into the problem the VScode requirements stated it does not support.
in addition, as i was remote connected as administrator , when using a 1.70.2 user setup ,a different warning message as follow was thrown:
This user Installer is not meant to be run as Administrator. If you would like to install VS Code for all users in this system, download the system Installer instead.Are you sure you want to continue?
as the installer itself also checks with the operator on this matter, your admin may have skipped on the exact reasons why the install failed and just told you the installer crashed.
if you absolutely need VScode to run on the server but can't install for reasons, the last resort (aside from going for alternatives like notepad++) is to Setup a Portable Mode builds on your own workstation/devices first, then upload the package to the server and use it from there.
i wouldn't go into too much detail in that as this reply already span for a starwars trilogy length but keep in mind, version limitations still apply, and whatever add-ons you need, you need to download them first before bundle it into the package to upload and run on your server.
Anyone that is a System admin or infrastructure architects , do correct me on my novice understanding on Server settings etc. as although i'm primarily a programmer, i did end up touching a lot more things that i'm not specialized into over the few years of vendor career work so there bound to be incorrect/inaccurate concepts i spilled. cheers.
Microsoft's own documentation provides the links to the images used for various operating systems, on top of which Microsoft-hosted agents get created.
For Windows Server 2019, the link shows bash as one of the tools included, and it also mentions WSL1 (Windows Subsystem for Linux v1) as installed. And it works just as expected, with Bash tasks running just fine inside Azure DevOps pipelines.
We're currently in the process of setting up our own self-hosted Windows agents, and we're looking for this capability as well. But to my knowledge, having Linux tools such as bash working on Windows requires 1) WSL installed and 2) a Linux distribution installed per a specific user. The procedure for deploying on Windows Server is here.
WSL doesn't currently have multiple-user support (GitHub issue here) and trying to run Linux tools as LOCAL SYSTEM presents challenges of their own. So in this context, how does the image used by the Microsoft-hosted Azure DevOps agents allow them to seamlessly run bash?
I heard about Cygwin, and know that it can provide similar functionality, but for now I'm trying to get bash configured similar to how it's done on Microsoft's own hosted agents.
As of this time, however, I think it is not supported running bash in Azure DevOps self-hosted Windows agent.
The Bash task runs on the agent as the user "NT Authority \ Network Service". However, we cannot install Linux distribution for this user. It will show that the user haven't logged in.
But for Microsoft, its virtual machines should have a specific user from whom bash starts rather than the default NT Authority \ Network Service.
I would like to know can we install and configure the windows self hosted agent on Azure Classic Machines? I have already created in ARM machines. I don't have classic machines from my end for testing but having at my client environment. We can't create Classic machines as well now (As it has been deprecated). Before requesting my client, I just want to get some clarity this is possible in the classic machines or not ?
Before requesting my client, I just want to get some clarity this is
possible in the classic machines or not ?
Classic mode is just one deployment model, just as Lex Li commented, the types of virtual machines doesn't matter in your scenario. Only the operating system makes sense for installation of self-hosted agents.
Check prerequisites of self-hosted agent:
Windows 7, 8.1, or 10 (if using a client OS)
Windows 2008 R2 SP1 or higher (if using a server OS)
PowerShell 3.0 or higher
.NET Framework 4.6.2 or higher
Only tips above have effect on the installation and usage of windows self agents. Hope it helps to resolve your puzzle.
I am working on a large scale ASP.NET web app.
The system is large enough to warrant monitoring systems, build scripts, source control server, etc etc.
I now want to setup a proper development environment whereby I have a development server, QA and staging.
I am going to be setting up Windows Server 2008 Standard Edition x64 (I have 4gb RAM so want to see all of it).
Would I just have to setup a VM for each environment? But the question this raises is that at the moment all my software is on Vista. It'd be good for each VM to have only the software it needs (e.g. I won't need Visual Studio on staging as I shouldn't change code on there) but I guess this can't be done? Should src control be on a central location and not in one of the environments (e.g. dev)? So something like:
Source control server
v
v
DEV
v
v
QA
v
v
Staging
And thus everything is decentralised.
How do you go about this?
Your idea of using 4 VMs should work well.
I don't see a database server of any type. I've found DBs do better on their own physical machine.
ADD MORE MEMORY!!!!! You want each machine to have enough memory.
Where can virtualization techniques be applied by an application developer? How can virtualization be applied on a day-to-day basis?
I would like to understand from veteran developers making use of it. I am interested in the following things:
How it helps in development.
How it could be used for testing purposes.
What are the recommended practices.
The main benefit, in my view, is that in a single machine, you can test an application in:
Different OSs, in case your app is multiplatform
Different configurations, like testing a client in one machine and a server in the other, or trying different parameters
Diffferent performance characteristics, like with minimal CPU and RAM, and with multicore and high amounts of RAM
Additionally, you can provide VM images to distribute applications preconfigured, be it for testing or for running applications in virtualized environments, where it makes sense (for apps which do not demand much power)
Can't say I'm a veteran developer, but I've used virtualization extensively when environments need to be controlled. That goes for:
Development: not only is it really useful to have VMs about for different deployment environments (e.g. browser versions, Windows XP / Vista / 7) but especially for maintenance it's handy to have a VM with the right development tools configured for a particular job.
Testing: this is where VMs really shine: it's great to have different deployment environments that can be set back to a known good configuration and multiple server instances running in parallel to test load balancing.
I've also found it useful to have a standard test image available that I can run locally to verify that a fix works. If it doesn't then I can roll back to the previous snapshot with no problems.
I've been using Virtual PC running Windows XP to test products I'm developing. I have clients who still need XP support while my primary dev environment is Vista (haven't had time to jump to Win7 yet), so having a virtual setup for XP is a big time saver.
Before each client drop, I build and test on my Vista dev machine then fire up VPC with XP, drag the binaries to the XP guest OS (enabled by installing Virtual PC additions on the guest OS) and run my tests there. I use the Undo disk feature of Virtual PC so I can always start with a clean XP image. This process would have been really cumbersome without virtualization.
I can now dump my old PCs at the local PC Recycle with no regrets :)
Some sort of test environment: if you are debugging malware (either writing it or developing a pill against it) it is not clever to use the real OS. The only possible disadvantage is that the viruses can detect that they are being run in the virtualization. :( One of the possibilities to do it is because the VM engines can emulate a finite set of hardware.