Integrates the whole stack into a single compose definition, complete with a custom ONI and ONI Agent build.
This is a complete change to how docker compose is used to manage NCA. The ONI Agent will be a real service running off an image that installs Open ONI. It will connect to a running ONI database, and a real ONI will be running using the same database. Basically ONI will run side-by-side with NCA and the ONI Agent will do what it's meant to do in a prod environment.
A new Dockerfile is added that describes both the ONI Agent and ONI itself. ONI's current Dockerfile requires the repo, as it uses ADD and COPY, and we don't actually publish a regularly-updated image, so it's easiest to just build one here. The agent needs an ONI install, so it just piggybacks off of the new Dockerfile and adjusts the entrypoint.
There are now two compose override examples: one that's semi-real-world where everything runs in containers, and one that supports the hybrid-dev approach.
The .env example is removed to simplify things: it's easier to direct people to use compose overrides rather than having two possible places things reside.
Normal contributors
I have done all of the following:
[x] Fixes and new features have unit tests where applicable
Closes #346
Integrates the whole stack into a single compose definition, complete with a custom ONI and ONI Agent build.
This is a complete change to how docker compose is used to manage NCA. The ONI Agent will be a real service running off an image that installs Open ONI. It will connect to a running ONI database, and a real ONI will be running using the same database. Basically ONI will run side-by-side with NCA and the ONI Agent will do what it's meant to do in a prod environment.
A new Dockerfile is added that describes both the ONI Agent and ONI itself. ONI's current Dockerfile requires the repo, as it uses ADD and COPY, and we don't actually publish a regularly-updated image, so it's easiest to just build one here. The agent needs an ONI install, so it just piggybacks off of the new Dockerfile and adjusts the entrypoint.
There are now two compose override examples: one that's semi-real-world where everything runs in containers, and one that supports the hybrid-dev approach.
The .env example is removed to simplify things: it's easier to direct people to use compose overrides rather than having two possible places things reside.
Normal contributors
I have done all of the following:
changelogs/(based onchangelogs/template.md)hugo/content/)