Running a service
Make sure to follow the recommendations for production when running services in a production or staging environment.
Running a Service with the CLI
The tomodachi
command-line interface (CLI) is used to run services defined as tomodachi
service classes. You can start a service with its class definition defined in ./service/app.py
by running tomodachi run service/app.py
. The service can be stopped with the keyboard interrupt <ctrl+c>
.
The CLI endpoint tomodachi
is installed automatically when the package is installed in the environment.
Command Line Arguments
The run
command has several options available that can be specified with arguments to the CLI. Here are the available arguments:
-
--loop [auto|asyncio|uvloop]
: This argument allows you to specify the event loop implementation. The value for--loop
can either be set toasyncio
,uvloop
orauto
. Theuvloop
value can only be used if uvloop is installed in the execution environment. Note that the defaultauto
value will currently end up using the event loop implementation that is preferred by the Python interpreter, which in most cases will beasyncio
. -
--production
: This argument disables the file watcher that restarts the service on file changes and hides the startup info banner. It's highly recommended to enable this option for built docker images and for builds of services that are to be released to any environment. -
--log-level [debug|info|warning|error|critical]
: This argument sets the minimum log level for which the loggers will emit logs to their handlers. By default, the minimum log level is set toinfo
. -
--logger [console|json|python|disabled]
: This argument changes the log formatter that is used by the library. The default valueconsole
is mostly suited for local development environments as it provides a structured and colorized view of log records. The console colors can be disabled by setting the env valueNO_COLOR=1
. -
--custom-logger <module.attribute|module>
: This argument allows you to specify a custom logger. If your logger is initialized in for example the moduleyourapp.logging
and the initialized (structlog
) logger is aptly namedlogger
, then use--custom-logger yourapp.logging.logger
. -
--opentelemetry-instrument
: Enables OpenTelemetry auto instrumentation of the service (including libraries for which the env has instrumentors installed). Mostly equivalent to starting the service using theopentelemetry-instrument
CLI, where OTEL distros, configurators and instrumentors will be loaded automatically andOTEL_*
environment values will be processed in the same way.
Environment Variables
Most options can also be set as an environment variable value. For example, setting environment TOMODACHI_LOGGER=json
will yield the same change to the logger as if running the service using the argument --logger json
. Here are the corresponding environment variables for the command line arguments:
TOMODACHI_LOOP=...
: Corresponds to--loop
.TOMODACHI_PRODUCTION=1
: Corresponds to--production
.TOMODACHI_LOG_LEVEL=...
: Corresponds to--log-level
.TOMODACHI_LOGGER=...
: Corresponds to--logger
.TOMODACHI_CUSTOM_LOGGER=...
: Corresponds to--custom-logger
.TOMODACHI_OPENTELEMETRY_INSTRUMENT=1
: Corresponds to--opentelemetry-instrument
# generic execution of services
app/ $ tomodachi run <service.py ...>
# example: if our service class exists in service/app.py
app/ $ tomodachi run service/app.py
Defaults to output startup banner on stdout and log output on stderr.
app/ $ tomodachi run service/app.py
HTTP services acts like a normal web server.
~/ $ curl -v "http://127.0.0.1:9700/resource/1234"
> HTTP/1.1 200 OK
> Content-Type: text/plain; charset=utf-8
> Server: tomodachi
> Content-Length: 9
> Date: Sun, 16 Oct 2022 13:38:02 GMT
>
> id = 1234
Updated about 1 year ago