| Name | fixinventoryworker JSON |
| Version |
4.2.0
JSON |
| download |
| home_page | None |
| Summary | Runs collector plugins and sends the result to fixcore. |
| upload_time | 2024-12-05 17:27:22 |
| maintainer | None |
| docs_url | None |
| author | Some Engineering Inc. |
| requires_python | >=3.12 |
| license | AGPLv3 |
| keywords |
|
| VCS |
 |
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
No coveralls.
|
# `fixworker`
Fix worker daemon
## Table of contents
* [Overview](#overview)
* [Usage](#usage)
* [Example usage](#example-usage)
* [Details](#details)
* [Actions and Tasks](#actions-and-tasks)
* [Actions](#actions)
* [Tasks](#tasks)
* [Contact](#contact)
* [License](#license)
## Overview
`fixworker` does all the collection and cleanup work in Fix. It is connected to [`fixcore`](../fixcore/) over a websocket connection and waits for instructions. By default it subscribes to the `collect` and `cleanup` actions as well as `tag` tasks.
`fixworker` loads collector [`plugins`](../plugins/) like AWS, GCP, Slack, Onelogin, etc.
Only those plugins have knowledge about how to communicate with each cloud. How to collect resources and how to clean them up.
There can be one or more instances of `fixworker` in a Fix deployment. A single `fixworker` can collect many clouds or you could have multiple `fixworker` collecting one cloud or even one account in one cloud each.
More information can be found below and in [the docs](https://inventory.fix.security/docs/concepts/components/worker).
## Usage
`fixworker` uses the following commandline arguments:
```
--subscriber-id SUBSCRIBER_ID
Unique subscriber ID (default: fix.worker)
--psk PSK Pre-shared key
--verbose, -v Verbose logging
--quiet Only log errors
--fixcore-uri FIXCORE_URI
fixcore URI (default: https://localhost:8900)
--override CONFIG_OVERRIDE [CONFIG_OVERRIDE ...]
Override config attribute(s)
--ca-cert CA_CERT Path to custom CA certificate file
--cert CERT Path to custom certificate file
--cert-key CERT_KEY Path to custom certificate key file
--cert-key-pass CERT_KEY_PASS
Passphrase for certificate key file
--no-verify-certs Turn off certificate verification
```
ENV Prefix: `FIXWORKER_`
Every CLI arg can also be specified using ENV variables.
For instance the boolean `--fork` would become `FIXWORKER_FORK=true`.
## Details
Once `fixworker` is started you do not have to interact with it at all. It will just sit there, wait for work and do its job. The following are details on how `fixworker` works internally and how it integrates with `fixcore`.
### Actions and Tasks
Think of actions and tasks like topics and queues in a messaging system. Actions are broadcast to everyone subscribed for that action. A task is always given to exactly one worker that knows how to handle it.
#### Actions
When the `collect` workflow within `fixcore` is triggered (by either an event or a schedule or because the user manually triggered it), `fixcore` will broadcast a ***"start collecting all the cloud accounts you know about"*** message to all the subscribed workers.
Once all the workers finish collecting and sent their graph to the core, the workflow will proceed to the next step which would be `plan_cleanup`. This one tells anyone interested to start planing their cleanup based on the just collected graph data. Once everyone has planed their cleanup and flagged resources that should get cleaned up with the `desired.clean = true` flag, the workflow proceeds to the `cleanup` step which again notifies anyone subscribed to now perform cleanup of those flagged resources. Because the cleaner within `fixworker` has knowledge of all dependencies in the graph, it will ensure that resources are cleaned up in the right order.
#### Tasks
When a plugin or a user decides that a resource tag should be added, changed or removed, e.g. by running
```
search id = i-039e06bb2539e5484 | tag update owner lukas
```
`fixcore` will put this tagging task onto a task queue. This task is then consumed by a `fixworker` that knows how to perform tagging for that particular resource and its particular cloud and account. In our example above where we are setting the tag `owner: lukas` for an AWS EC2 instance with ID `i-039e06bb2539e5484` the task would be given to a `fixworker` that knows how to update AWS EC2 instance tags in that resources account.
## Contact
If you have any questions feel free to [join our Discord](https://discord.gg/fixsecurity) or [open a GitHub issue](https://github.com/someengineering/fix/issues/new).
## License
See [LICENSE](../LICENSE) for details.
Raw data
{
"_id": null,
"home_page": null,
"name": "fixinventoryworker",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.12",
"maintainer_email": null,
"keywords": null,
"author": "Some Engineering Inc.",
"author_email": null,
"download_url": "https://files.pythonhosted.org/packages/db/36/7856e6006003f6f31618c16ebb517671d0869dfc2f79a04d86e22bd92b5e/fixinventoryworker-4.2.0.tar.gz",
"platform": null,
"description": "# `fixworker`\nFix worker daemon\n\n\n## Table of contents\n\n* [Overview](#overview)\n* [Usage](#usage)\n * [Example usage](#example-usage)\n* [Details](#details)\n * [Actions and Tasks](#actions-and-tasks)\n * [Actions](#actions)\n * [Tasks](#tasks)\n* [Contact](#contact)\n* [License](#license)\n\n\n## Overview\n`fixworker` does all the collection and cleanup work in Fix. It is connected to [`fixcore`](../fixcore/) over a websocket connection and waits for instructions. By default it subscribes to the `collect` and `cleanup` actions as well as `tag` tasks.\n\n`fixworker` loads collector [`plugins`](../plugins/) like AWS, GCP, Slack, Onelogin, etc.\nOnly those plugins have knowledge about how to communicate with each cloud. How to collect resources and how to clean them up.\n\nThere can be one or more instances of `fixworker` in a Fix deployment. A single `fixworker` can collect many clouds or you could have multiple `fixworker` collecting one cloud or even one account in one cloud each.\n\nMore information can be found below and in [the docs](https://inventory.fix.security/docs/concepts/components/worker).\n\n\n## Usage\n`fixworker` uses the following commandline arguments:\n```\n --subscriber-id SUBSCRIBER_ID\n Unique subscriber ID (default: fix.worker)\n --psk PSK Pre-shared key\n --verbose, -v Verbose logging\n --quiet Only log errors\n --fixcore-uri FIXCORE_URI\n fixcore URI (default: https://localhost:8900)\n --override CONFIG_OVERRIDE [CONFIG_OVERRIDE ...]\n Override config attribute(s)\n --ca-cert CA_CERT Path to custom CA certificate file\n --cert CERT Path to custom certificate file\n --cert-key CERT_KEY Path to custom certificate key file\n --cert-key-pass CERT_KEY_PASS\n Passphrase for certificate key file\n --no-verify-certs Turn off certificate verification\n```\n\nENV Prefix: `FIXWORKER_`\nEvery CLI arg can also be specified using ENV variables.\n\nFor instance the boolean `--fork` would become `FIXWORKER_FORK=true`.\n\n\n## Details\nOnce `fixworker` is started you do not have to interact with it at all. It will just sit there, wait for work and do its job. The following are details on how `fixworker` works internally and how it integrates with `fixcore`.\n\n\n### Actions and Tasks\nThink of actions and tasks like topics and queues in a messaging system. Actions are broadcast to everyone subscribed for that action. A task is always given to exactly one worker that knows how to handle it.\n\n\n#### Actions\nWhen the `collect` workflow within `fixcore` is triggered (by either an event or a schedule or because the user manually triggered it), `fixcore` will broadcast a ***\"start collecting all the cloud accounts you know about\"*** message to all the subscribed workers.\nOnce all the workers finish collecting and sent their graph to the core, the workflow will proceed to the next step which would be `plan_cleanup`. This one tells anyone interested to start planing their cleanup based on the just collected graph data. Once everyone has planed their cleanup and flagged resources that should get cleaned up with the `desired.clean = true` flag, the workflow proceeds to the `cleanup` step which again notifies anyone subscribed to now perform cleanup of those flagged resources. Because the cleaner within `fixworker` has knowledge of all dependencies in the graph, it will ensure that resources are cleaned up in the right order.\n\n\n#### Tasks\nWhen a plugin or a user decides that a resource tag should be added, changed or removed, e.g. by running\n```\nsearch id = i-039e06bb2539e5484 | tag update owner lukas\n```\n`fixcore` will put this tagging task onto a task queue. This task is then consumed by a `fixworker` that knows how to perform tagging for that particular resource and its particular cloud and account. In our example above where we are setting the tag `owner: lukas` for an AWS EC2 instance with ID `i-039e06bb2539e5484` the task would be given to a `fixworker` that knows how to update AWS EC2 instance tags in that resources account.\n\n\n## Contact\nIf you have any questions feel free to [join our Discord](https://discord.gg/fixsecurity) or [open a GitHub issue](https://github.com/someengineering/fix/issues/new).\n\n\n## License\nSee [LICENSE](../LICENSE) for details.\n",
"bugtrack_url": null,
"license": "AGPLv3",
"summary": "Runs collector plugins and sends the result to fixcore.",
"version": "4.2.0",
"project_urls": {
"Documentation": "https://inventory.fix.security",
"Source": "https://github.com/someengineering/fix/tree/main/fixworker"
},
"split_keywords": [],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "5442bf91559f29b65d534ef2905a45bdef6b4f4e6ab548e6163d2fef9c966507",
"md5": "7fa4219a49753215b09ac199df617613",
"sha256": "2b21bd93595ea23b7aa35bb294795e91a59fdf68d45101370957a6da7bd9630e"
},
"downloads": -1,
"filename": "fixinventoryworker-4.2.0-py3-none-any.whl",
"has_sig": false,
"md5_digest": "7fa4219a49753215b09ac199df617613",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.12",
"size": 23262,
"upload_time": "2024-12-05T17:27:21",
"upload_time_iso_8601": "2024-12-05T17:27:21.502717Z",
"url": "https://files.pythonhosted.org/packages/54/42/bf91559f29b65d534ef2905a45bdef6b4f4e6ab548e6163d2fef9c966507/fixinventoryworker-4.2.0-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "db367856e6006003f6f31618c16ebb517671d0869dfc2f79a04d86e22bd92b5e",
"md5": "508910a9a97b0715cb2c915d6cd18dba",
"sha256": "556dda848b3298416a90510f34173ccfb41ff253b2e51f7b3d10ba6a20b9de42"
},
"downloads": -1,
"filename": "fixinventoryworker-4.2.0.tar.gz",
"has_sig": false,
"md5_digest": "508910a9a97b0715cb2c915d6cd18dba",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.12",
"size": 18345,
"upload_time": "2024-12-05T17:27:22",
"upload_time_iso_8601": "2024-12-05T17:27:22.465742Z",
"url": "https://files.pythonhosted.org/packages/db/36/7856e6006003f6f31618c16ebb517671d0869dfc2f79a04d86e22bd92b5e/fixinventoryworker-4.2.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-12-05 17:27:22",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "someengineering",
"github_project": "fix",
"github_not_found": true,
"lcname": "fixinventoryworker"
}
