1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
# NGINX Unit Rust SDK and CLI
This project provides a Rust SDK interface to the
[NGINX Unit](https://unit.nginx.org/)
[control API](https://unit.nginx.org/howto/source/#source-startup)
and a CLI (`unitctl`) that exposes the functionality provided by the SDK.
## Installation and Use
In order to build and use `unitctl` one needs a working installation of
Cargo. It is recommended to procure Cargo with Rustup. Rustup is packaged
for use in many systems, but you can also find it at its
[Official Site](https://rustup.rs/). Additionally, Macintosh users will
need to install GNU core utilities using brew (see the following command)
```
$ brew install make gnu-sed grep gawk maven
```
After installing a modern distribution of Make, Macintosh users can invoke
the makefile commands using `gmake`. For example: `gmake clean` or `gmake all`.
Finally, in order to run the OpenAPI code generation tooling, Users will
need a working
[Java runtime](https://www.java.com/en/)
as well as Maven. Macintosh users can install Maven from Brew.
With a working installation of Cargo it is advised to build unitctl with the
provided makefile. The `list-targets` target will inform the user of what
platforms are available to be built. One or more of these can then be run as
their own makefile targets. Alternatively, all available binary targets can be
built with `make all`. See the below example for illustration:
```
[ava@calliope cli]$ make list-targets
x86_64-unknown-linux-gnu
[ava@calliope cli]$ make x86_64-unknown-linux-gnu
▶ building unitctl with flags [--quiet --release --bin unitctl --target x86_64-unknown-linux-gnu]
[ava@calliope cli]$ file ./target/x86_64-unknown-linux-gnu/release/unitctl
./target/x86_64-unknown-linux-gnu/release/unitctl: ELF 64-bit LSB pie executable,
x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=ef4b094ffd549b39a8cb27a7ba2cc0dbad87a3bc, for GNU/Linux 4.4.0,
with debug_info, not stripped
```
As demonstrated in the example above, compiled binaries may be found in the
targets folder, under the subdirectory corresponding to the build target
desired.
## Features (Current)
- Consumes alternative configuration formats Like YAML and converts them
- Syntactic highlighting of JSON output
- Interpretation of Unit errors with (arguably more) useful error messages
### Lists all running Unit processes and provides details about each process.
```
$ unitctl instances
No socket path provided - attempting to detect from running instance
unitd instance [pid: 79489, version: 1.32.0]:
Executable: /opt/unit/sbin/unitd
API control unix socket: unix:/opt/unit/control.unit.sock
Child processes ids: 79489, 79489
Runtime flags: --no-daemon
Configure options: --prefix=/opt/unit --user=elijah --group=elijah --openssl
```
### Start a new Unit process via docker
```
$ unitctl instances new /tmp/2 $(pwd) 'unit:wasm'
Pulling and starting a container from unit:wasm
Will mount /tmp/2 to /var/run for socket access
Will READ ONLY mount /home/ava/repositories/nginx/unit/tools/unitctl to /www for application access
Note: Container will be on host network
```
To the subcommand `unitctl instances new` the user must provide three things:
1. **A directory such as `/tmp/2`.**
The Unit container will mount this to `/var/run` internally.
Thus, the control socket and pid file will be accessible from the host.
2. **A path to an application.**
In the example, `$(pwd)` is provided. The Unit container will mount
this READ ONLY to `/www/`. This will allow the user to configure
their Unit container to expose an application stored on the host.
3. **An image tag.**
In the example, `unit:wasm` is used. This will be the image that unitctl
will deploy. Custom repos and images can be deployed in this manner.
After deployment the user will have one Unit container running on the host network.
### Lists active listeners from running Unit processes
```
unitctl listeners
No socket path provided - attempting to detect from running instance
{
"127.0.0.1:8080": {
"pass": "routes"
}
}
```
### Get the current status of NGINX Unit processes
```
$ unitctl status -t yaml
No socket path provided - attempting to detect from running instance
connections:
accepted: 0
active: 0
idle: 0
closed: 0
requests:
total: 0
applications: {}
```
### Send arbitrary configuration payloads to Unit
```
$ echo '{
"listeners": {
"127.0.0.1:8080": {
"pass": "routes"
}
},
"routes": [
{
"action": {
"share": "/www/data$uri"
}
}
]
}' | unitctl execute --http-method PUT --path /config -f -
{
"success": "Reconfiguration done."
}
```
### Edit current configuration in your favorite editor
```
$ unitctl edit
[[EDITOR LOADS SHOWING CURRENT CONFIGURATION - USER EDITS AND SAVES]]
{
"success": "Reconfiguration done."
}
```
### Import configuration, certificates, and NJS modules from directory
```
$ unitctl import /opt/unit/config
Imported /opt/unit/config/certificates/snake.pem -> /certificates/snake.pem
Imported /opt/unit/config/hello.js -> /js_modules/hello.js
Imported /opt/unit/config/put.json -> /config
Imported 3 files
```
### Wait for socket to become available
```
$ unitctl --wait-timeout-seconds=3 --wait-max-tries=4 import /opt/unit/config`
Waiting for 3s control socket to be available try 2/4...
Waiting for 3s control socket to be available try 3/4...
Waiting for 3s control socket to be available try 4/4...
Timeout waiting for unit to start has been exceeded
```
|
