Persistent Data #123
Labels
enhancement
New feature or request
Comments
|
@schrieveslaach I have managed to implement persistence for both docker and kubernetes. |
|
@samuchila, I see you are making progress and I think my comment here should provide some basic structuring to be able to serve all mentioned use cases within this issue which can be implemented first for Docker and then for Kubernetes. Please, have a look and lets focus on Docker first. |
schrieveslaach
added a commit
that referenced
this issue
Jan 11, 2024
This commit introduces the configuration `bootstrapping.containers` which provides a way to parse the configuration of application wide companions because the current available configuration of companions if quite limiting (Current backends, Docker and Kubernetes, offer way more options than the PREvant configuration object allows). For example, PREvant was limited to self-contained applications where each microservice only relies on interactions via network API calls (REST, database connections, messaging, etc.) With this commit PREvant is now able to deploy application companions that are more powerful than the PREvant configuration in Kubernetes backends. If `bootstrapping.containers` is defined, PREvant will start one or more containers on the infrastructure backend that are expected to generate Kubernetes manifests as output on standard out (stdout) that will be parsed by PREvant and supported are: - roles and role bindings - config maps and secrets - service accounts - persistent volume claims - services - pods, deployments, stateful sets, and jobs Then before deploying these manifests PREvant merges all objects with the objects generated from the HTTP request payload. Thus you can add or overwrite configurations. For example, you can change the image used or an environment variable. If you overwrite any configuration the companion will be turned into an instance (as PREvant did before). Ingresses won't be deployed if the bootstrap container outputs one of these. Instead they will be parsed and if they use the ingress class `nginx` they will be transformed into Traefik ingresses and middlewares so that the microservices will be available via web interface. This approach make #143 obsolete and fixes #123
schrieveslaach
added a commit
that referenced
this issue
Jan 11, 2024
This commit introduces the configuration `bootstrapping.containers` which provides a way to parse the configuration of application wide companions because the current available configuration of companions if quite limiting (Current backends, Docker and Kubernetes, offer way more options than the PREvant configuration object allows). For example, PREvant was limited to self-contained applications where each microservice only relies on interactions via network API calls (REST, database connections, messaging, etc.) With this commit PREvant is now able to deploy application companions that are more powerful than the PREvant configuration in Kubernetes backends. If `bootstrapping.containers` is defined, PREvant will start one or more containers on the infrastructure backend that are expected to generate Kubernetes manifests as output on standard out (stdout) that will be parsed by PREvant and supported are: - roles and role bindings - config maps and secrets - service accounts - persistent volume claims - services - pods, deployments, stateful sets, and jobs Then before deploying these manifests PREvant merges all objects with the objects generated from the HTTP request payload. Thus you can add or overwrite configurations. For example, you can change the image used or an environment variable. If you overwrite any configuration the companion will be turned into an instance (as PREvant did before). Ingresses won't be deployed if the bootstrap container outputs one of these. Instead they will be parsed and if they use the ingress class `nginx` they will be transformed into Traefik ingresses and middlewares so that the microservices will be available via web interface. This approach make #143 obsolete and fixes #123 and contributes to #146.
schrieveslaach
added a commit
that referenced
this issue
Jan 11, 2024
This commit introduces the configuration `bootstrapping.containers` which provides a way to parse the configuration of application wide companions because the current available configuration of companions if quite limiting (Current backends, Docker and Kubernetes, offer way more options than the PREvant configuration object allows). For example, PREvant was limited to self-contained applications where each microservice only relies on interactions via network API calls (REST, database connections, messaging, etc.) With this commit PREvant is now able to deploy application companions that are more powerful than the PREvant configuration in Kubernetes backends. If `bootstrapping.containers` is defined, PREvant will start one or more containers on the infrastructure backend that are expected to generate Kubernetes manifests as output on standard out (stdout) that will be parsed by PREvant and supported are: - roles and role bindings - config maps and secrets - service accounts - persistent volume claims - services - pods, deployments, stateful sets, and jobs Then before deploying these manifests PREvant merges all objects with the objects generated from the HTTP request payload. Thus you can add or overwrite configurations. For example, you can change the image used or an environment variable. If you overwrite any configuration the companion will be turned into an instance (as PREvant did before). Ingresses won't be deployed if the bootstrap container outputs one of these. Instead they will be parsed and if they use the ingress class `nginx` they will be transformed into Traefik ingresses and middlewares so that the microservices will be available via web interface. This approach make #143 obsolete and fixes #123 and contributes to #146.
schrieveslaach
added a commit
that referenced
this issue
Jan 15, 2024
This commit introduces the configuration `bootstrapping.containers` which provides a way to parse the configuration of application wide companions because the current available configuration of companions if quite limiting (Current backends, Docker and Kubernetes, offer way more options than the PREvant configuration object allows). For example, PREvant was limited to self-contained applications where each microservice only relies on interactions via network API calls (REST, database connections, messaging, etc.) With this commit PREvant is now able to deploy application companions that are more powerful than the PREvant configuration in Kubernetes backends. If `bootstrapping.containers` is defined, PREvant will start one or more containers on the infrastructure backend that are expected to generate Kubernetes manifests as output on standard out (stdout) that will be parsed by PREvant and supported are: - roles and role bindings - config maps and secrets - service accounts - persistent volume claims - services - pods, deployments, stateful sets, and jobs Then before deploying these manifests PREvant merges all objects with the objects generated from the HTTP request payload. Thus you can add or overwrite configurations. For example, you can change the image used or an environment variable. If you overwrite any configuration the companion will be turned into an instance (as PREvant did before). Ingresses won't be deployed if the bootstrap container outputs one of these. Instead they will be parsed and if they use the ingress class `nginx` they will be transformed into Traefik ingresses and middlewares so that the microservices will be available via web interface. This approach make #143 obsolete and fixes #123 and contributes to #146.
schrieveslaach
added a commit
that referenced
this issue
Jan 23, 2024
This commit introduces the configuration `bootstrapping.containers` which provides a way to parse the configuration of application wide companions because the current available configuration of companions if quite limiting (Current backends, Docker and Kubernetes, offer way more options than the PREvant configuration object allows). For example, PREvant was limited to self-contained applications where each microservice only relies on interactions via network API calls (REST, database connections, messaging, etc.) With this commit PREvant is now able to deploy application companions that are more powerful than the PREvant configuration in Kubernetes backends. If `bootstrapping.containers` is defined, PREvant will start one or more containers on the infrastructure backend that are expected to generate Kubernetes manifests as output on standard out (stdout) that will be parsed by PREvant and supported are: - roles and role bindings - config maps and secrets - service accounts - persistent volume claims - services - pods, deployments, stateful sets, and jobs Then before deploying these manifests PREvant merges all objects with the objects generated from the HTTP request payload. Thus you can add or overwrite configurations. For example, you can change the image used or an environment variable. If you overwrite any configuration the companion will be turned into an instance (as PREvant did before). Ingresses won't be deployed if the bootstrap container outputs one of these. Instead they will be parsed and if they use the ingress class `nginx` they will be transformed into Traefik ingresses and middlewares so that the microservices will be available via web interface. This approach make #143 obsolete and fixes #123 and contributes to #146.
schrieveslaach
added a commit
that referenced
this issue
Jan 24, 2024
This commit introduces the configuration `bootstrapping.containers` which provides a way to parse the configuration of application wide companions because the current available configuration of companions if quite limiting (Current backends, Docker and Kubernetes, offer way more options than the PREvant configuration object allows). For example, PREvant was limited to self-contained applications where each microservice only relies on interactions via network API calls (REST, database connections, messaging, etc.) With this commit PREvant is now able to deploy application companions that are more powerful than the PREvant configuration in Kubernetes backends. If `bootstrapping.containers` is defined, PREvant will start one or more containers on the infrastructure backend that are expected to generate Kubernetes manifests as output on standard out (stdout) that will be parsed by PREvant and supported are: - roles and role bindings - config maps and secrets - service accounts - persistent volume claims - services - pods, deployments, stateful sets, and jobs Then before deploying these manifests PREvant merges all objects with the objects generated from the HTTP request payload. Thus you can add or overwrite configurations. For example, you can change the image used or an environment variable. If you overwrite any configuration the companion will be turned into an instance (as PREvant did before). Ingresses won't be deployed if the bootstrap container outputs one of these. Instead they will be parsed and if they use the ingress class `nginx` they will be transformed into Traefik ingresses and middlewares so that the microservices will be available via web interface. This approach make #143 obsolete and fixes #123 and contributes to #146.
schrieveslaach
added a commit
that referenced
this issue
Jan 25, 2024
Bootstrap Companions in Kubernetes Environments This commit introduces the configuration `bootstrapping.containers` which provides a way to parse the configuration of application wide companions because the current available configuration of companions if quite limiting (Current backends, Docker and Kubernetes, offer way more options than the PREvant configuration object allows). For example, PREvant was limited to self-contained applications where each microservice only relies on interactions via network API calls (REST, database connections, messaging, etc.) With this commit PREvant is now able to deploy application companions that are more powerful than the PREvant configuration in Kubernetes backends. If `bootstrapping.containers` is defined, PREvant will start one or more containers on the infrastructure backend that are expected to generate Kubernetes manifests as output on standard out (stdout) that will be parsed by PREvant and supported are: - roles and role bindings - config maps and secrets - service accounts - persistent volume claims - services - pods, deployments, stateful sets, and jobs Then before deploying these manifests PREvant merges all objects with the objects generated from the HTTP request payload. Thus you can add or overwrite configurations. For example, you can change the image used or an environment variable. If you overwrite any configuration the companion will be turned into an instance (as PREvant did before). Ingresses won't be deployed if the bootstrap container outputs one of these. Instead they will be parsed and if they use the ingress class `nginx` they will be transformed into Traefik ingresses and middlewares so that the microservices will be available via web interface. This approach make #143 obsolete and fixes #123 and contributes to #146. This commit also ensures that there are less requests to the Kubernetes API, improving the performance.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the moment PREvant does not provide any option to ensure that the data of a service or companion will be persisted. For example, if someone operates a PostgreSQL database on a Kubernetes cluster and the container will be moved to another node, all data will be lost for this application (Kafka is another example).
Further, people report to me personally, that they need a way of sharing data between different services or companions (even when Microservices shouldn't be synchronized via file system because it is the worst option)
Anyways, PREvant should allow that services or companions are able to store data. Here are some ideas:
registry.rscan be enhanced not just returning the port but also including the list of exposed volumes (according to the specThe text was updated successfully, but these errors were encountered: