Having a platform that enables ChatOps can be a game changer. You can quickly see changes, alerts, build status, discussions, emergency chats, and more, all in a single, searchable interface. If you can sift through the gifs. Bots are a hot topic these days, and and it’s well worth checking out Matt Hodgkins bit on integrating PowerShell with Hubot. Bots are a great alternative to trying to spin up a web front end for PowerShell. On top of bots, systems like Slack often offer a wealth of integrations, allowing you to hook into systems like Nagios, PagerDuty, GitHub, Trello, and many others. Occasionally, you might have something that doesn’t integrate natively. Maybe you want to integrate Slack messages into your SCOM command notification channel, your CI/CD build process, orchestration system, configuration management systems, or even ad hoc scripts. If you’re using Slack, check out the Slack API methods, or an incoming webhook. With the API in particular, you can do some handy stuff! If you like the idea of re-usable tools and abstraction, check out PSSlack, a PowerShell module that we’re starting to build out, which can simplify sending messages, searching messages, and more.
Having an understanding of your systems performance is a crucial part of running IT infrastructure. If a user comes to us and says “why is my application running slowly?”, where do we start? Is it their machine? Is it the database server? Is it the file server? The first thing we usually do is open up perfmon.exe and take a look at some performance counters. You then see the CPU on the database server is 100% and think _ “was the CPU always at 100% or did this issue just start today? Was it something I changed? If only I could see what was happening at this time yesterday when the application was running fine!". _It might take you a few hours to find the performance issue on your infrastructure, and you are probably going to need to open up perfmon.exe on a couple of other systems. There is a better way! What if you could turn your Windows performance counters into dashboards that look like this? How much time would you save? Using a combination of the open source tools InfluxDB to store the performance counter data, **Grafana **to graph the data and the Telegraf agent to collect Windows performance counters, you will be a master of your metrics in no time! Read the detailed walk through over at hodgkins.io
A couple of weeks ago, DevOps Collective (PowerShell.org’s parent non-profit organization) announced the availability of the ‘GetGoing’ IT Ops Education Program and Scholarship. For those of you who may not have yet heard, DevOps Collective and Pluralsight have partnered together to create a modern ’turnkey’ curriculum that brings together mapped courses, recommended hands-on experiences, and live mentoring to prepare people for the real-world of IT Operations. With this initiative, they’ve offered up to full-ride scholarships for 2016. Applications for the scholarship have opened, and applications will be taken in until May 15th. Now that the way has been paved, it’s our turn as members of the community to get the word out; and doing so might be easier than you think! Contact Your Local School Districts I recently reached out to my hometown public school district, and was immediately met with enthusiasm from the local superintendent and their Science, Guidance, and Counseling departments. It only takes a quick email with some bullet points on the program to get the conversation initiated. I’ve included the text of my initial correspondence for you to use as a guide to help you on your way. Contacting your school district is
easy
. A quick search online for your district can get your to their website with contact info, often including the email addresses for the district superintendent and other office officials that can help! Send them a copy of the brochure to help them get informed of the initiative. Use Your Social Media Skills Get the conversation going on social media! Talk to your followers; speak out to local educational organizations; and make them aware of this awesome new program! Inform Your User Groups Get your user groups in on the action. Enlist the greater community to get the word out faster! Together we can canvas an even larger area and get more people interested! Get Involved Offer to become a mentor. We all know that the best way to learn is from real world experiences. We, as a community, have this vast repository of practical knowledge that no book can effectively provide. We, as a collective resource, can help to bring a new generation of administrators, engineers, and architects into this world already prepared to take on DevOps, Agile IT, and more! If you need a hand getting started, feel free to contact me at webmaster at powershell.org. Now let’s #GetGoing ourselves, and make this happen! Here’s my initial contact email that you can use to fit your own story: Greetings [Contact Name],
If you are not on Office 365 or have a tenant set up with Microsoft yet, now is the time to reserve your tenant name! With utilizing Office 365, a lot of administration is only available from a PowerShell session. There is a mix of outdated information on what you actually need to install and execute in order to connect to all of the Office 365 services. As a result, I accumulated and wrote up the current download requirements and commands to connect and administer every Office 365 service from one PowerShell session. I hope this saves everyone a lot of time and effort! Head over to PowerShellBlogger.com to read the full article here.
ChatOps is a term used to describe bringing development or operations work that is already happening in the background into a common chat room. It involves having everyone in the team in a single chat room, then bringing tools into the room so everyone can automate, collaborate and see how automation is used to solve problems. In doing so, you are unifying the communication about what work gets done and have a history of it happening. ChatOps can be supplemented with the use of tools or scripts exposed using a chat bot. Users in the chat room can talk to the bot and have it take actions on their behalf, some examples of this may be:
Creating windows shortcuts are usually done through the New Shortcut Wizard, MSI files, Group Policy Objects, or even a simple file copy. Shortcut files are .lnk files that Microsoft Windows uses for shortcuts to local files while .url is used for destinations such as web sites. As we all are aware, the .lnk filename extension is hidden in Windows Explorer even when “Hide extensions for known file types” is unchecked in File Type options. The reason for this is the NeverShowExt string value in HKEY_CLASSES_ROOT\lnkfile. Shortcuts are also displayed with a curled arrow overlay icon. The IsShortcut string value causes the arrow to be displayed. For a full run down on creating shortcuts and favorites with PowerShell head over to PowerShellBlogger.com.
I am back this week with a quick how-to article on delivering, installing, or launching version controlled files. In the past I ran into problems when having administrators launch my PowerShell tools from a network share. The performance was slow when launching it across the WAN, and the file would often be locked when I tried to replace it with a newer version. I came up with a solution to the problem by using none other than PowerShell. The solution dips into all kinds of PowerShell techniques including local environment variables, getting text file contents, file version checking and even shortcut (.lnk) creation. If you are also a user of Sapien’s PowerShell Studio, then definitely give this one a read. Check out the solution over on PowerShellBlogger.com.
Want to see what a real-world, functional, production-grade DevOps environment looks like? Look no further than Amazon Web Services’ Elastic Beanstalk (EBS). EBS is a neat combination of their EC2 IaaS product, S3 storage, and some DevOps magic. From a working perspective, it goes something like this:
Developer checks code into Git. A portion of this code is actually a set of EBS directives, outlining changes that need to be made to the base operating environment. This can include things like setting environment variables, installing packages, and so on.
Someone indicates that what’s in GitHub is ready for release. You can do this by pushing a button in your AWS console, or by making a call to AWS’ REST APIs. It’s pretty easy to automat this step.
AWS spins up virtual machines, and reads the EBS directives to get that environment configured the way it’s supposed to be. The code is loaded from Git into the VMs. The VMs are registered with AWS’ load balancer, and whatever old VMs were running are de-registered and destroyed. Poof, your app is up and running.
This model accomplishes the basic goal of DevOps, which is to shorten the path between developers and users. So where’s the “Ops” role in all this? Amazon did it. Their contribution to ops was to create all the automation necessary to make these steps happen. And the beauty of this model is that it supports tiered environments. For example, the above three steps might serve to spin up a testing environment, where you then run automated tests to validate the code. If the code validates, it’s pushed into a production tier - all automatically - running on a separate EBS application. So from check-in to in-production is entirely automated, and the process can be performed consistently every single time. Now… what would this look like in a Windows world? In Step 1, imagine that instead of a set of EBS configuration directives - which are just text files - your developers create DSC configurations. Yes, the developers. After all, they’re the ones who are coding for the environment, so that DSC configuration documents what they need the environment to look like. You might have a second DSC configuration that documents corporate standards for security, manageability, and so on. Whatever. Step 3 might be Microsoft Azure Pack or System Center Virtual Machine Manager, told - perhaps via an SMA automation script - to spin up the new VMs from a base OS image. The DSC configurations are run to produce a MOF, which is injected into the new VM. The developer’s code is deployed to the VM. The VM is registered with DNS and perhaps a load balancer, which provide access to it. There are a couple of important details that I’ve glossed over a bit. Jeffrey Snover is fond saying, “treat servers like cattle, not pets.” But servers by their nature have to have a few unique pieces of information, right? Well… yes and no. For all I know, cows make up names for themselves. I just don’t care. Take IP addresses, for example. You shouldn’t be assigning static IP addresses to servers; your DHCP system should be highly available, fault tolerant, and set up to handle servers. As you spin up a new VM, you can obviously have it register itself with DNS, so the IP address is mapped to a hostname. And speaking of that hostname - you as a human never need to know it. Or you shouldn’t. Windows will make up a host name for itself as the VM spins up, and you can - through your automation scripts - capture that host name. That lets you set up DNS CNAME records, a load balancer, or whatever else. The point is that while the server may have made up a name for itself, you don’t care. Nobody will ever address that server by its host name - they’ll use an abstraction, like a load-balanced name, or a CNAME, or something else. Your automation scripts handle the mapping for you. When a VM is spun down, automation de-registers the dying host’s name from whatever, closing the lifecycle loop. Interestingly, you could probably do this exact model, today, with a huge number of applications in your environment. Why bother? I mean, this model makes sense in web apps where you’re constantly spinning up and destroying VMs, but what about the majority of your apps that just run all the time without change? Well, this same model could spin them up in a disaster recovery scenario. Or in testing environments, which are constantly re-created to provide “clean” tests. Yes, it’s a lot of investment up front to make it all work, but once it’s set up it just runs itself. And that’s what DevOps looks like.
A couple of weeks ago, DevOps Collective (PowerShell.org’s parent non-profit organization)