I am trying to use PowerShell DSC to deploy our software to client PCs; in most of the DSC tutorials or examples that I have seen, DSC seems to be used to deploy server software.
Does it make sense to use DSC for client PCs?
Notes :
I have already tried deployment with the classic .MSI packages; it doesn't work very well in our case for various reasons, and we would really benefit from the fact that DSC deployments can automatically "heal" in case of problems.
I use puppet to deploy the server-side software; it works fine, but puppet doesn't seem to be a good fit for client PCs (therefore PowerShell DSC).
DSC does ship in the client. When we say DSC is for configuring servers it means we will target scenarios specific to the server. However, with the existing features if you can solve a scenario in client, feel free to do so.
Dsc is oriented for server , where a configuration is global for the system (like a database , web or file server).
Users can have differents settings on the same machine , dsc is not the best solution to deal with that usecase.
Anyway, for package deployment you can look at Oneget or Chovolatey ;)
Related
I have some .exe files which i need to install on VMs in azure using azure automation powershell DSC. Is this possible and how can it be done? The exe files are currently stored in an azure file share.
A similar question was asked here The answer provided was:
If you want to do the install the EXE remotely then the VM needs to be configured to allow for remote management - you can do this via WinRM. See: https://www.penflip.com/powershellorg/secrets-of-powershell-remoting/blob/master/accessing-remote-computers.txt and http://tarkus.me/post/64761019099/windows-azure-vms-remote-management
Setting this up is non-trivial (you need to ensure it's secure). You could also try adding an VM extension to the VM that will do the copy. Since the VM is already provision I think the only option here would be to use DSC though I've never added a DSC extension to a VM post-provisioning, it should work. That would require authoring and staging a DSC script in addition to adding the extension but definitely less complex than enabling remote management.
You should also consider Azure automation, depending on how large scale is your automation projects are. You can find more info and tutorials here
Newbie to automated azure deployment here! I have the happy task of automating our deployment to the cloud. I have also done some reading and discovered that the 2 main tools are MSbuild and Powershell. Please could anyone tell me why i would use one over the other or indeed if there are any better ways to automate the deployment. Keeping in mind that my main concern is performance and i need this deplymrnt to be as fast as possible.
Any insight would be most welcome.
I'm a fan of using PowerShell for deployments. It's pretty quick to set up and the script can be pretty straight forward.
MSBuild can be great too. I use MSBuild from TFS Team Build to kick off a PowerShell script to do the deployment. Works like a champ.
A good starting point would be http://blogs.msdn.com/b/tomholl/archive/2011/12/06/automated-build-and-deployment-with-windows-azure-sdk-1-6.aspx. This blog does a great job of showing you how to build and deploy with Team Build.
If you don't want/need the Team Build and MSBuild part, then just look at his PowerShell script. That covers the basics of getting a deployment from your dev environment to Windows Azure.
You should use Web Deploy, it only takes about a minute to deploy a fix. See these links
http://blogs.msdn.com/b/cloud/archive/2011/04/19/enabling-web-deploy-for-windows-azure-web-roles-with-visual-studio.aspx
http://channel9.msdn.com/Blogs/funkyonex/Speed-Up-Azure-Deployments-with-the-New-Web-Deployment-Feature
At SplendidCRM, we had a similar need to automate deployments to Azure, but as our need was to service our live customers, we had to develop using C#. We have been watching Azure for many years, but it was not until they provided a DNS service did it make sense to make the move. Using the Azure Resource Manager (ARM) libraries, we were able to automate VM creation, SQL database creation and DNS name creation. In addition to the Microsoft documentation for ARM, we found it particularly useful to be able to get the Microsoft source code for the PowerShell scripts that wrap ARM. This is because the documentation does not always provide a complete set of settings.
In the end, we decided to release the Azure deployment code as part of a new Ultimate edition that combines order and customer management with software deployment.
I am supposed to fulfill a common-for-most-developers request to build/consume secure services using ssl/tls... via various communication protocols, not necessary wcf (web) services.
My problem is that I don't know much about certificates and I have been trying to get my background knowledge up to speed on the entire process.
The organization I am coordinating with issued 3 files for me to use:
AppName.cert.pem
AppName.csr
AppName.Key.pem
and also gave me a password for these.
The organization also gave me another certificate:
Organization.cert.pem
which is supposed to be used with their test tools.
The scenario is that the organization provided a test suite that runs on one vm, and the software I am building on another. I am supposed to import both of the certs into the vm with my software, and I think the organization's cert into the vm with the test software.
Problem is I don't know how, and the help links they provided are pointing to OpenSSL and some Java2SE tracing the secure requests/responses from either side....
Well, my code is written in C#, and both VM's use Windows Server 2008R2 x64 Standard/Enterprise. I am not sure how to import the certs, and configure them a) on a per application basis for a specific PORT and b) per domain basis?
Thanks,
Any help and guidance would be greatly appreciated!
Well, I downloaded the OpenSSL windows client and converted the AppName.cert.pem, AppName.csr AppName.Key.pem into a single consolidated AppName.PKCS12.
I later imported the result using the Cert Manager (MMC Snap In) in each WS2008R2 VM environment and it worked just fine.
It turns out that the Cert Manager also does understand what is a *.cert.pem file so I was able to import the Organization.cert.pem as well on both VM's.
Thanks
PS: Never read instructions about Windows config written by a Linux/Unix nut-job. This whole exercise of certificate management would've been easier if the person that wrote the test software manual (which I ported from Linux by the way...) didn't send me on a wild goose chase due to his lack of understanding of the capabilities of the Windows Server Environment... No need for OpenSSL.
<bleepzter/>
I have found an example of running Tomcat in Windows Azure, but JBoss seems to be a bit trickier. Has anyone succeeded in running JBoss in Windows Azure, and if so, what should I do to get it running?
I would like to know if JBoss can be run in a worker role, not the VM role which is currently in beta.
I'd recommend trying it and asking questions as you get roadblocked. Most "does this run in Azure" questions are answered with "yes", but full-fledged examples and guides are going to be sparse as the platform is very new. So be the guy who writes it :)
You have two options with something like this:
1.) Run a worker role that invokes and runs similar to a windows service. (most tomcat on azure guides approach this way)
2.) Use a Azure Startup task to install, configure, start jBoss as a windows service and/or on top of tomcat
With the addition of full-trust, startup tasks, RDP, and eventually even VMrole .. anything that can run on a Windows 2008 server can run on Azure. So try installing on a Windows box, document those steps, then 1 by 1, figure out the "azure way" to accomplish those tasks. Approached this way, the initial setup will likely be pretty simple. From there, you'll learn a lot about Azure's offerings and can probably even make some changes to better leverage the platform for JBoss needs.
Once you get up there and have issues, ask away and you're more likely to find direct answers by the audience of MVPs, Azure team members, and cloud geeks here vs just a generic "have you done this" answer.
Recently, I've joined the Windows team in my enterprise and with my developer background (Java, .NET and Web in general), I was pretty quickly interested in PowerShell. I can see its value over plain old batch files, VB, ... which is why I'd like to promote its usage and, little by little, push people to favor it over the rest unless there's a reason not to do so.
Deploying PowerShell seems pretty straightforward since we can easily approve the relevant patches in WSUS and configure the execution policy via GPO for the AD integrated servers.
My questions are in fact more about the distribution and usage of PowerShell and PowerShell modules (e.g., PCSX, PowerShellPack, home made, ...).
For those of you who have already deployed PowerShell in your enterprise:
Do you have some sort of standard package for PowerShell with a set of modules that you deploy on each server? If you do, then how do you deploy new versions of the installed modules?
Did you put a central PowerShell repository in place where you store all your PowerShell modules? If so, is that repository accessible globally or do you also secondary repositories that you synchronize?
I'm pretty used to tools such as Maven, Ivy and other dependency management software, which is why I'm a bit disappointed by what PowerShell has to offer in this regard.
I've found a very nice article about this subject and will probably go down the same path, as it corresponds to my requirements.
Do you use WinRM? Do you connect directly from workstations or do you have central management servers? Did you limit access to WinRM to those management servers?
Do you use WinRM in a non-managed environment (servers not in an AD domain)? How do you configure WinRM?
We have a network zone in which the servers aren't part of an AD domain, thus I can't rely on the Kerberos authentication for WinRM.
Globally, what is your experience, are you satisfied with the results?
Edit:
Regarding question 2, we've decided to put a central repository in place.
The idea will be to have a main repository which will be under version control (GIT) and to which we'll be the only ones to have write access.
From that repository, we will copy the modules using an rsync like tool (in our case that'll be robocopy) to other secondary repositories (which will be read-only copies). Only those repositories will be accessible by the clients (we'll just have to update the PSModulePath on those clients to make sure they can access the repository).
We'll also stage our releases, thus in the repository, there'll be multiple versions available: Development, Integration and Production.
Let's cover each issue by category.
Evangelism
To start off interest in PowerShell to your coworkers, I would suggest starting off with the bread and butter of automation. Find a common pain point that is relatively easy to implement (to get something out there in front of your coworkers quickly) and automate it with PowerShell. Then expand from there.
Another good idea is to start a "Script Club" at your office where you do some training and share ideas or problems about scripting in PowerShell. You can start out with once every few weeks and see how it goes. At my work, we have a book club where we go through various technical books on testing, design, and programming, it works well.
Packaging
Modules - PowerShell modules are the best form of packaging. They are quite easy to use and offer some nice features such as easy deployment and private variables/functions.
Scripts - Scripts are a good idea for work-in-progress or to start off since your coworkers will certainly be comfortable with scripts.
Deployment
There are a few options currently for deployment.
Deploy to every machine - This could avoid some network issues and gives you more flexibility with each machine, but the downside is that updating modules may be more of a pain.
Central repository (a.k.a. a network share) - You could also store all your modules on a central network share. This would avoid issues with deploying to every machine and you can make the modules read-only if you want to control modifications. But you would still have to deploy a profile to each machine to add the network share to the $env:PSModulePath variable. It would be best to set this in the all-users-all-hosts profile. From then on you shouldn't need to update it unless the path changes.
NuGet - NuGet is an open source project that is bringing package management to .NET development. What is nice about it is the ability to have public repositories and local/private repositories. There is already an initial version of a PowerShell module that will leverage NuGet for PowerShell module deployment.
Remote Access
Being a build engineer, I have relatively few machines and full control over them. So I have remoting enabled. You would have to ask some IT guys for better advice.