Exploring the new DevOps - Azure Command Line Interface 2.0 (CLI)
Sponsored By
I'm a huge fan of the command line, and sometimes I feel like Windows people are missing out on the power of text mode. Fortunately, today Windows 10 has bash (via Ubuntu on Windows 10), PowerShell, and "classic" CMD. I use all three, myself.
Five years ago I started managing my Azure cloud web apps using the Azure CLI. I've been a huge fan of it ever since. It was written in node.js, it worked the same everywhere, and it got the job done.
Fast forward to today and the Azure team just announced a complete Azure CLI re-write, and now 2.0 is out, today. Initially I was concerned it had been re-written and didn't understand the philosophy behind it. But I understand it now. While it works on Windows (my daily driver) it's architecturally aligned with Mac and (mostly, IMHO) Linux users. It also supports new thinking around a modern command line with support for things like JMESPath, a query language for JSON. It works well and clearly with the usual suspects of course, like grep, jq, cut, etc. It's easily installed with pip, or you just get Python 3.5.x and then just "pip install --user azure-cli."
Linux people (feel free to check the script) can just do this curl, but it's also in apt-get, of course.
curl -L https://aka.ms/InstallAzureCli | bash
NOTE: Since I already have the older Azure CLI 1.0 on my machine, it's useful to note that these two CLIs can live on the same machine. The new one is "az" and the older is "azure," so no problems there.
Or, for those of you who run individual Docker containers for your tools (or if you're just wanting to explore) you can
docker run -v ${HOME}:/root -it azuresdk/azure-cli-python:<version>Then I just "az login" and I'm off! Here I'll query my subscriptions:
C:\Users\scott\Desktop> az account list --output table
Name CloudName Sub State IsDefault
------------------------------------------- ----------- --- ------- -----------
3-Month Free Trial AzureCloud 0f3 Enabled
Pay-As-You-Go AzureCloud 34c Enabled
Windows Azure MSDN AzureCloud ffb Enabled True
At this point, it's already feeling familiar. It's "az noun verb" and there's an optional --output parameter. If I don't include --output by default I'll get JSON...which I can then query with JMESPath if I'd like. (Those of us who are older may be having a little XML/XPath/XQuery déjà vu)
I can use JSON, TSV, tables, and even "colorized json" or JSONC.
C:\Users\scott\Desktop> az appservice plan list --output table
AppServicePlanName GeoRegion Kind Location Status
-------------------- ---------------- ------ ---------------- --------
Default1 North Central US app North Central US Ready
Default1 Southeast Asia app Southeast Asia Ready
Default1 West Europe app West Europe Ready
DefaultServerFarm West US app West US Ready
myEchoHostingPlan North Central US app North Central US Ready
I can make and manage basically anything. Here I'll make a new App Service Plan and put two web apps in it, all managed in a group:
az group create -n MyResourceGroup # Create an Azure AppService that we can use to host multiple web apps
az appservice plan create -n MyAppServicePlan -g MyResourceGroup
# Create two web apps within the appservice (note: name param must be a unique DNS entry)
az appservice web create -n MyWebApp43432 -g MyResourceGroup --plan MyAppServicePlan
az appservice web create -n MyWEbApp43433 -g MyResourceGroup --plan MyAppServicePlan
You might be thinking this looks like PowerShell. Why not use PowerShell? Remember this isn't for Windows primarily. There's a ton of DevOps happening in Python on Linux/Mac and this fits very nicely into that. For those of us (myself included) who are PowerShell fans, PowerShell has massive and complete Azure Support. Of course, while the bash folks will need to use JMESPath to simulate passing objects around, PowerShell can keep on keeping on. There's a command line for everyone.
It’s easy to get started with the CLI at http://aka.ms/CLI and learn about the command line with docs and samples. Check out topics like installing and updating the CLI, working with Virtual Machines, creating a complete Linux environment including VMs, Scale Sets, Storage, and network, and deploying Azure Web Apps – and let them know what you think at azfeedback@microsoft.com. Also, as always, the Azure CLI 2.0 is open source and on GitHub.
Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test, build and debug ASP.NET, .NET Framework, .NET Core, or Unity applications. Learn more and get access to early builds!
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
March 02, 2017 11:14
What are the differences between the parameters without dashes or with single or double dashes?
Ahmed Magdy
Oh so YOU'RE the reason why we've regressed into DOS6.2 with our current "state of the art" developer experience? :P Honestly, you need both CLI and GUI. CLI is powerful, but error-prone and difficult to discover. You are dealing with an input device (keyboard) with 100+ keys versus another (mouse) with 1 or 2, after all.
Also, there's something to be said about offering an IDE that costs however-many-dollars-per-seat, but is now requiring its users to also switch over to an application/experience that MSFT conceded waaaaayyyyyyy back in 1995 was not the most ideal approach for its users to be effective (and, uh, happy). Why are we now paying so much for an IDE that doesn't capture all the features and functionality of a rudimentary experience? This is the whole point of a visual application experience, after all.
In any case, it would be great to see some innovation in this area so that when developers create an "application", scaffolding is involved so that *BOTH* CLI and GUI equivalents are created, thereby reaching/satisfying both segments, rather than perpetuating/reinforcing the confusing (and costly) divide as it exists today.
Also, there's something to be said about offering an IDE that costs however-many-dollars-per-seat, but is now requiring its users to also switch over to an application/experience that MSFT conceded waaaaayyyyyyy back in 1995 was not the most ideal approach for its users to be effective (and, uh, happy). Why are we now paying so much for an IDE that doesn't capture all the features and functionality of a rudimentary experience? This is the whole point of a visual application experience, after all.
In any case, it would be great to see some innovation in this area so that when developers create an "application", scaffolding is involved so that *BOTH* CLI and GUI equivalents are created, thereby reaching/satisfying both segments, rather than perpetuating/reinforcing the confusing (and costly) divide as it exists today.
I was interested in JMESPath and how it compares with OData as they seem to do the same thing. There is not even a Wikipedia entry for it which makes me think it's very new. There is this StackOverflow question which needs some love.
@Mike-EEE - Blasphemy!
Everyone knows GUIs with friendly and intuitive context-sensitive menus and interfaces we've all grown up with that have become second nature to all of us are out. Memorizing thousands of commands, each with umpteen parameters on an unforgiving command line is clearly better and the future.
Yes, I'm (we're?) getting old. So in closing, get off my lawn! :)
Everyone knows GUIs with friendly and intuitive context-sensitive menus and interfaces we've all grown up with that have become second nature to all of us are out. Memorizing thousands of commands, each with umpteen parameters on an unforgiving command line is clearly better and the future.
Yes, I'm (we're?) getting old. So in closing, get off my lawn! :)
I always wonder why some developers complain about command line tools and memorizing commands and parameters. Do they use drag and drop to do their programming? :)
The primary benefit of CLI based tools is the ability to script them. GUI has it's place, but it's much more difficult to automate point and click tasks.
I appreciate that you think CLI is cool Scott and perhaps nostalgia contributes to making you so excited to use it. But I seriously think you're in denial if you believe its the most efficient way for you to accomplish most tasks or investigate status. A well-designed GUI is far more efficient for this type of thing.
Yes, it's good for scripting and the only option for those who refuse to use anything but VIM for development. But I'll go out on a limb here and say those are the minority use cases. Yet MS for the past few years has heavily focused on command line features at the expense of improving GUI.
No one is going to go to their boss and pitch using Azure or .NET because of its nifty command line. A big reason people chose MS products is because of the ease of development- much of which comes from superior GUI.
Yes, it's good for scripting and the only option for those who refuse to use anything but VIM for development. But I'll go out on a limb here and say those are the minority use cases. Yet MS for the past few years has heavily focused on command line features at the expense of improving GUI.
No one is going to go to their boss and pitch using Azure or .NET because of its nifty command line. A big reason people chose MS products is because of the ease of development- much of which comes from superior GUI.
@Sam >> No one is going to go to their boss and pitch using Azure or .NET because of its nifty command line.
"No one" is a bit broad. As you admit, command lines are useful for scripting, which means that processes may be automated and done in a consistent manner. That's important for all kinds of applications. If I couldn't have provided scripted deployment to Azure, we wouldn't be using Azure today.
Neither GUI nor CLI is better than the other... they both have their uses. My personal favorite is an approach where the CLI either directly uses the same underlying API's used by the GUI, or the GUI translates the call into the command line. Either way, behavior is identical between the two systems, and you can use the interface that is best for what you're trying to accomplish.
"No one" is a bit broad. As you admit, command lines are useful for scripting, which means that processes may be automated and done in a consistent manner. That's important for all kinds of applications. If I couldn't have provided scripted deployment to Azure, we wouldn't be using Azure today.
Neither GUI nor CLI is better than the other... they both have their uses. My personal favorite is an approach where the CLI either directly uses the same underlying API's used by the GUI, or the GUI translates the call into the command line. Either way, behavior is identical between the two systems, and you can use the interface that is best for what you're trying to accomplish.
GUI is nice thing to have, but CLI can be automated and scripted. Therefor, CLI is required, GUI is optional.
GUI only is why I've avoided MS tools for anything beyond the desktop and why I would only choose *nix systems. It just didn't scale. But that's the MSFT of old and not of tomorrow.
In order to actually be competitive, and for the Windows community to grow beyond the desktop, there are the tried and true tools and concepts that will take us to the next level. I welcome all of this change with open arms. I just hope we don't spend too much time storming and can get to norming.
In order to actually be competitive, and for the Windows community to grow beyond the desktop, there are the tried and true tools and concepts that will take us to the next level. I welcome all of this change with open arms. I just hope we don't spend too much time storming and can get to norming.
We (Microsoft platform developers) have always been treated to every single command being put in various Visual Studio versions over the years, so I guess we're used to and we tend to need'em otherwise we kinda panic in front of the black window...
Problem is those IDEs have grown and grown to be huge and now you have so many menus and items that... you get lost... How many items are in the contextual menu in a code behind window? Too many...
I always think about how complex it is to maintain Visual Studio, like an OS i believe.
The new Microsft, also, is introducing use of lots of Open Source software also for developers. You cannot expect Microsoft to author all the UI needed to interface with all those tools.
Bottom line is: we'd better get accustomed to a lot of black windows (not widows :) ) without panicking any more.
Problem is those IDEs have grown and grown to be huge and now you have so many menus and items that... you get lost... How many items are in the contextual menu in a code behind window? Too many...
I always think about how complex it is to maintain Visual Studio, like an OS i believe.
The new Microsft, also, is introducing use of lots of Open Source software also for developers. You cannot expect Microsoft to author all the UI needed to interface with all those tools.
Bottom line is: we'd better get accustomed to a lot of black windows (not widows :) ) without panicking any more.
Isn't there a happy medium in here somewhere? Tooling runs on scripts and CLI, GUI's generate those scripts?
Discoverability is near zero on a CLI, but if you had a GUI helping to discover features and build the scripts then you'd have a path from zero to hero.
Discoverability is near zero on a CLI, but if you had a GUI helping to discover features and build the scripts then you'd have a path from zero to hero.
Discoverability is not near zero on a CLI. A decent CLI will guide you through its abilities. Additionally, not every .NET developer is just a .NET developer. As polyglot programmer, CLI foo is much more transferrable between environments.
Don't think of it as GUI vs CLI. Think of it as natural interface and programmatic interface. The CLI is sometimes the programmatic interface and sometimes the natural interface.
If you absolutely, positively, only have the resources to produce one, there's good reason to make it the CLI. But preferably, make a GUI available. Even more preferably, make a library available, and make it the foundation of both a GUI and a CLI. People who want to live inside the CLI, or who prefer to use it for something particular, can use it. People who want to live inside the GUI, or who prefer to use it for something particular, can use it. And people who don't want their build scripts to be prone to "duck typing" problems and "screen scraping" can benefit from a library.
It's not a battle. A knife is not better than a fork. Sometimes you need different tools for different tasks, and sometimes you even need different tools for what looks like the same task. Take NuGet. project.json and now The New csproj makes it easy to batch edit package versions in text. The Package Manager GUI in Visual Studio makes it easy to search for packages. Both involve enumerating and installing packages. Ask someone to use the wrong tool for it and you're asking them to have a horrible time - or "experience", since that seems to be Microsoft-speak for this kind of thing.
I appreciate Visual Studio Code, I appreciate the emergence of command line savvy, I understand that a lot of things must now be built with a focus to be cross-platform, and I welcome Microsoft out of its cocoon into the real world where we can now use its solutions to solve more problems. But the exodus of GUI focus does worry me, and it's just one facet of something that's being left behind.
Similarly, documentation is being compartmentalized to extremely specific articles written at one point in time, and to anemic API documents, instead of the actually helpful level of the MSDN documentation. Look up System.String's class page, for example; ASP.NET MVC has been miles from this for years, as anyone who's tried to figure out the requirements of the object-typed parameters in the route mapping methods know. (Yes, I do appreciate Intellisense. No, it is emphatically not the same thing as written documentation. No, knowing something is a string tells me absolutely nothing. And no, knowing something is an interface provided by the framework tells me absolutely nothing about why and where I would use it. Types are great but they don't excuse documentation.)
If you absolutely, positively, only have the resources to produce one, there's good reason to make it the CLI. But preferably, make a GUI available. Even more preferably, make a library available, and make it the foundation of both a GUI and a CLI. People who want to live inside the CLI, or who prefer to use it for something particular, can use it. People who want to live inside the GUI, or who prefer to use it for something particular, can use it. And people who don't want their build scripts to be prone to "duck typing" problems and "screen scraping" can benefit from a library.
It's not a battle. A knife is not better than a fork. Sometimes you need different tools for different tasks, and sometimes you even need different tools for what looks like the same task. Take NuGet. project.json and now The New csproj makes it easy to batch edit package versions in text. The Package Manager GUI in Visual Studio makes it easy to search for packages. Both involve enumerating and installing packages. Ask someone to use the wrong tool for it and you're asking them to have a horrible time - or "experience", since that seems to be Microsoft-speak for this kind of thing.
I appreciate Visual Studio Code, I appreciate the emergence of command line savvy, I understand that a lot of things must now be built with a focus to be cross-platform, and I welcome Microsoft out of its cocoon into the real world where we can now use its solutions to solve more problems. But the exodus of GUI focus does worry me, and it's just one facet of something that's being left behind.
Similarly, documentation is being compartmentalized to extremely specific articles written at one point in time, and to anemic API documents, instead of the actually helpful level of the MSDN documentation. Look up System.String's class page, for example; ASP.NET MVC has been miles from this for years, as anyone who's tried to figure out the requirements of the object-typed parameters in the route mapping methods know. (Yes, I do appreciate Intellisense. No, it is emphatically not the same thing as written documentation. No, knowing something is a string tells me absolutely nothing. And no, knowing something is an interface provided by the framework tells me absolutely nothing about why and where I would use it. Types are great but they don't excuse documentation.)
There already is a GUI for working with Azure: the online portal.
Use whichever interface you like most.
Use whichever interface you like most.
Just what I was searching for, thanks for posting.
Feel free to visit my web site; kamasutra and esdorts in UK;
tantricescorts.co.uk,
Feel free to visit my web site; kamasutra and esdorts in UK;
tantricescorts.co.uk,
If you are Microsoft developer using VISUAL Studio for the last 20 years, going back to a CLI seems like a HUGE step backwards. If you are Node.JS dev who has been coding on a Mac for the last five years and you use CLI then a GUI might seem slower then what you can do with CLI. Neither is better, but most of the current .net coders who have been coding for 10 years or more NEVER use a CLI. Nor do we want to start now because the Node.JS and Linux folks haven't had the luxury of not needing one. It is all what you are used to and comfortable with. It isn't about one being better than the other.
I could see a CLI vs GUI debate if there was only one or the other, but the fact is, there's numerous ways of interacting with Azure, including:
- The portal(s)
- CLI
- Powershell
- REST API, with wrappers for just about every modern language
Use what works for you.
I personally use all of them: portal for monitoring and when I feel like using a GUI, Powershell for my deployment scripts and experiments (configuring a VM with 16 disks is a pain in the portal), and the REST API for managing specific services my apps require (e.g. provisioning new SQL Azure DBs for new clients).
- The portal(s)
- CLI
- Powershell
- REST API, with wrappers for just about every modern language
Use what works for you.
I personally use all of them: portal for monitoring and when I feel like using a GUI, Powershell for my deployment scripts and experiments (configuring a VM with 16 disks is a pain in the portal), and the REST API for managing specific services my apps require (e.g. provisioning new SQL Azure DBs for new clients).
Scott, you can also use the new CLI via Docker on Windows. That sample command line you posted only works for Linux.
CLI is great for scripting and can eliminate mistakes like when one of our server admins deleted a production VM by clicking the wrong server. He meant to delete the one above mine.
Starting out in the DOS world, the list of commands was small and easily memorized. I was doing some work via powershell lately and the syntax, well, was stupid long and overly complex. But that's what you get when you have so many commands at your fingertips.
I do a lot of database work in SQL Server. I can visualize the database better when I use SQL Server Management Studio in design view for creating tables and all the things that go along with it. Certainly, I can write everything in T-SQL to accomplish the same tasks, but I don't do it every day and sometimes don't quite get the syntax down right.
SSMS gets it right in that I can do all this work in the GUI and save it out to a script. If I need to pass it to a DBA, another developer, or run it in batch after hours, I have the freedom to do that. If other tools were to follow this model, CLI wouldn't be as big a barrier to some.
Starting out in the DOS world, the list of commands was small and easily memorized. I was doing some work via powershell lately and the syntax, well, was stupid long and overly complex. But that's what you get when you have so many commands at your fingertips.
I do a lot of database work in SQL Server. I can visualize the database better when I use SQL Server Management Studio in design view for creating tables and all the things that go along with it. Certainly, I can write everything in T-SQL to accomplish the same tasks, but I don't do it every day and sometimes don't quite get the syntax down right.
SSMS gets it right in that I can do all this work in the GUI and save it out to a script. If I need to pass it to a DBA, another developer, or run it in batch after hours, I have the freedom to do that. If other tools were to follow this model, CLI wouldn't be as big a barrier to some.
"Anyone who deploys by point-and-click user interfaces is, of course, living in a state of sin." -- Alfred E. Neuman
GUI is for learning. CLI is how you get the things done. Use them together. Use them in peace.
The main problem for me with gui's is that it has additional overhead to write and maintain. Next to this ui styles seem to change all the time. This wouldn't be a problem during initial development but it just becomes annoying when maintaining or even just using the programs you wrote many years ago.
The cli is a way more stable interface across multiple platforms.
The cli is a way more stable interface across multiple platforms.
Saying that CLI can be scripted is mostly because no one has bothered to make a proper GUI. Having grown up in the VAX era, the current GUI stuff seems a bliss and I absolutely loathe this approach of more CLI. Why not just make the damn GUIs better, huh? Why not have the options in the GUI to repeat this, or automate that, or schedule sumtin' or other?
Bah humbug sayeth the old guy ;-)
Bah humbug sayeth the old guy ;-)
Is this the beginning of the end for Power Shell? Too bad in that case, it was a nice idea but the CLI with objects approach never really worked that well I guess. Sad to see it go, but happy if it means bash on Windows will get 100% focus and evolve into something grand!
I'm a bit confused at all the hate directed at this feature. First, as many note, everything you can do in the CLI you can do in the Azure portal and vice versa. They have different purposes. The GUI is great when you're exploring options and experimenting. But then when you start repeating building stuff over and over for testing, and/or working with multiple developers, and certainly when you move into production, you want to be able to store infrastructure as code so you can do change management, easy replication and automation. No GUI can do any of those.
Coming from AWS I find it especially impressive how in the portal GUI you get the ARM scripts for CLI which you can then use to easily automate replication of complex infrastructure. Pretty neat and a huge timesaver!
Coming from AWS I find it especially impressive how in the portal GUI you get the ARM scripts for CLI which you can then use to easily automate replication of complex infrastructure. Pretty neat and a huge timesaver!
GGRRROOOOAAAANNNNNNNNnnnnnnnnnnnnnnnn............
People do not LOVE command lines, nor do developers.....
i mean there was a time, where there was a think called DOS and Microsoft Became the super power house it is today by offering people a GUI! first in windows 3.1 and then more so in win 95! when treat developers any different? they are the end users of the system, the fact that they write software some how means that they want to go back to command line? NOOOOOO!
even with ASP.NET the GUI to click and drag controls and such, is now gone with MVC, i think that MS is pan handling to "geeks" rather than professional developers, and its being pan handled by other head GEEKs to get street cred! but they fail to realise that people LOVED their IDE's and GUIs they dont want command line, if they did they would go and take up linx, java, and ror,....
Look, all I want is a way to easier and faster to do my job at work, and typing isn’t the way to go, its moving my mouse and pressing, buttons, if anything offer both options,.. pretty disappointed with the way MS has been going for the last few years.
People do not LOVE command lines, nor do developers.....
i mean there was a time, where there was a think called DOS and Microsoft Became the super power house it is today by offering people a GUI! first in windows 3.1 and then more so in win 95! when treat developers any different? they are the end users of the system, the fact that they write software some how means that they want to go back to command line? NOOOOOO!
even with ASP.NET the GUI to click and drag controls and such, is now gone with MVC, i think that MS is pan handling to "geeks" rather than professional developers, and its being pan handled by other head GEEKs to get street cred! but they fail to realise that people LOVED their IDE's and GUIs they dont want command line, if they did they would go and take up linx, java, and ror,....
Look, all I want is a way to easier and faster to do my job at work, and typing isn’t the way to go, its moving my mouse and pressing, buttons, if anything offer both options,.. pretty disappointed with the way MS has been going for the last few years.
Great discussion, thanks for the post.
https://msdn.microsoft.com/en-us/library/windows/desktop/dn688964(v=vs.85).aspx
This is the Windows design guide. As a Windows programmer, I am seriously ticked when programmers do not follow this. Why? Because it means that you don't know what you are doing. Of course Windows needs a CLI, but Windows has an overall coherence because of its GUI. It is the reason that I like working in a Windows environment and other geeks like NIX. Slap a GUI on Linux but never remove the CLI coherence. Same goes in reverse for Windows.
https://msdn.microsoft.com/en-us/library/windows/desktop/dn688964(v=vs.85).aspx
This is the Windows design guide. As a Windows programmer, I am seriously ticked when programmers do not follow this. Why? Because it means that you don't know what you are doing. Of course Windows needs a CLI, but Windows has an overall coherence because of its GUI. It is the reason that I like working in a Windows environment and other geeks like NIX. Slap a GUI on Linux but never remove the CLI coherence. Same goes in reverse for Windows.
Comments are closed.