Command line tool for supporting Nox projects
View the documentation »
View Demo
·
Report Bug
·
Request Feature
Nox.Cli is a companion command-line tool that supports the core Nox library. Its raison d'être is to build upon Nox's strong efficiency focus by extending that vision to the entire Enterprise Software Roadmap. This includes fast-tracking of DevOps functions like deployment to multiple environments, setting up CI/CD pipelines and configuring resource permissions. This is achieved by integrating seamlessly with existing enterprise assets and services like Helm charts, Azure KeyVault and Active Directory.
Nox.Cli is declarative in nature with the primary aim of describing a project or solution. It uses a range of plugin technologies in the development, infrastructure and DevOps realms to rapidly configure and deploy a solution in the enterprise.
- Accelerate and simplify the development and deployment of enterprise-grade microservices**
- Cross-platform implementation with support for Windows, Linux and MacOS
- Easy to install and run on developer/engineer desktop or integrate directly into DevOps pipeline
- Workflows use YAML-syntax and is based on GitHub Actions
- Self-documentation of project workflow to fast-track productivity of all team members that work on a project
- Open-source plugin-based architecture allows for using/customising existing actions or developing your own
- Users are identified based on Azure Login or other interactive authorisation service
- Input commands (workflows) can be project-specific or organisation-centric by way of a Tenant manifest maintained by DevOps
- Both project and Tenant KeyVaults are supported
- Can be used both for local development environment and DevOps pipeline
- Central management and deployment of common organisational scripts
- Automatically updates scripts and notifies developers of version updates
- Support secure remote task execution
** In conjunction with the Nox.NET library
The section below will walk you though installation of the Nox.Cli tool as well as a sample project to illustrate how simple it is to set up set up the associated DevOps environment.
Make sure you have .NET 6.0 or later installed on your PC.
dotnet --versionIf you don't have .NET installed you can download the latest version here.
The Nox.Cli tool is hosted on nuget.org here and additional installation options are detailed there. The recommended installation method is outlined below: -
dotnet tool install --global Nox.CliRunning the Nox.Cli tool installation with the global option yields the following output:
Running Nox.Cli for the first time yields the following output:
nox
💡 You may notice from the screenshot that if you are logged in to Azure it will automatically use these credentials. In the instance that you're not logged into Azure you will be redirected to Microsoft login screen in a browser:
💡 The second important thing to note is that apart from the
--versionand--logoutcommands, the additional commands listed above are dynamically added from the workflows folder in your local repository or from a script repository which is linked to your organisation, hosted athttps://noxorg.dev/workflows/{tenant.id}/index.php
The development project built for our Nox sample was a simple currency microservice with all the expected CRUD endpoints to add & maintain the currencies of our choice. We're going to use the Nox.Cli companion tool to set up the entire DevOps environment that accompanies that project.
Running the nox new command outlines its usage options as seen below:
nox new
Let's create a folder for our project and run the nox new service command from within the newly created folder:
mkdir CurrencyConverter
cd .\CurrencyConverter\
nox new serviceA series of questions follows which will determine the initial configuration of our project environment. Upon completion of the input, these options will be saved into the project configuration file called {service.name}.service.nox.yaml
As you can see, the service configuration file is now present in our default project directory. Opening this file in a code editor of your choice will reveal configuration options that echoes your input from the preceding interactive step.
The YAML file is registered with schema.org so we get linting and auto-completion to ensure accuracy and speed in configuring our service. The schema used to describe our sample project can be viewed here.
Now we have defined the project attributes but all we have is a simple YAML file, but no environment as yet. Well this is where the magic really starts. We'll turn our attention to the nox sync command and its various options to read our project configuration file and set up the project environment as per our input.
nox sync
This step will go and check the specified DevOps server and create our version control repository if not already present.
nox sync version-control
Subsequent to running this command a cursory glance at our DevOps server will reveal the newly created project.
nox sync azure-active-directory
You'll notice that your project group have now been created on Azure Active Directory.
If you click on the Members link of the group you'll seet that the users are as per your earlier project configuration.
nox sync database
nox sync helm-chart
Having a look at your project on the DevOps server will reveal that the Helm Chart repo have been created.
And selecting the App.Helmchart repo will show the relevant files.
The manifest file is tasked with propogating the enterprise-level configurations related to our project. It is hosted in a tenant-specific folder on the Nox website and would typically be maintained by the DevOps team.
Firstly, the secrets: section is where we link to our secrets provider and vault url.
The branches: section is where we specify the command 'categories'—for the lack of a more tech-propriate term.
You'll recall from running the nox command previously that it listed the new, sync and version commands as options. We'll disregard the logout command for now as it's baked into the tool. You will however see how these three commands have been propogated from the manifest file.
Reviewing the various workflow yaml files will show how commands and their aliases are linked to the branches, outlined above. In the NewNoxService.workflow.nox.yaml example above, we can see how the service command, the sv alias and |sv - Creates a new NOX app/service description is linked to the new branch.
Further examination of the file will also reveal the various steps performed as part of the workflow.
Similarly, in the SyncDatabaseScript.workflow.nox.yaml example below, we can see how the database command, the db alias and |db - Ensures hosted database and roles exist for your NOX definition description is linked to the sync branch.
And the output when running the nox sync command without any arguments reflect this:
Finally, the remote-task-proxy: section points to the url and authorisation-provide for the remote task executor which will conver in more detail later.
Contributions are what make the open source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.
If you have a suggestion that would make this better, please fork the repo and create a pull request. You can also simply open an issue with the tag "enhancement". Don't forget to give the project a star! Thanks again!
- Fork the Project
- Create your Feature Branch (
git checkout -b feature/AmazingFeature) - Commit your Changes (
git commit -m 'Add some AmazingFeature') - Push to the Branch (
git push origin feature/AmazingFeature) - Open a Pull Request
Distributed under the MIT License. See LICENSE.txt for more information.
Twitter: @AndreSharpe72
Project Link: https://github.com/noxorg/nox.cli
- Nox was inspired and draws heavily from Paul DeVito's very impressive Wrapt project. Nox is essentially (a less feature-rich) Wrapt without the code generation and aims to keep developer code 100% separate from the framework, and imposes no constraints on application architechture.
- Nox would not have been possible without the many open-source projects that it draws from. The goal is to build on top of an already rich ecosystem of great libraries and tools like Microsoft's .NetCore, YamlDotNet, NewtonSoft.Json, Hangfire, Serilog, SqlKata, ETLBox, Entity Framework, MassTransit and others.