A backend to REST Layer that stores configuration in a Kubernetes ConfigMap.
Further reading about ConfigMaps:
See examples/main.go for usage example.
- Offers CRUD-style REST API functionality
- Can manage ConfigMaps in the namespace it is installed to or in any other namespace (given sufficient access privileges)
- Maintains original ConfigMap labels on Update
If you're using the GB build tool, you can fetch all dependencies using the following commands:
gb vendor fetch github.com/justinas/alice
gb vendor fetch github.com/rs/cors
gb vendor fetch github.com/rs/rest-layer/resource
gb vendor fetch github.com/rs/rest-layer/rest
gb vendor fetch github.com/rs/zerolog
gb vendor fetch github.com/rs/zerolog/hlog
gb vendor fetch github.com/rs/zerolog/log
gb vendor fetch github.com/segence/rest-layer-kubernetes-configmap
The library can access any Kubernetes namespace as long as it has permissions (which can be controlled through RBAC, for example).
The client has to be configred with a default Kubernetes namespace, like in the following code example:
kHandler := configmap.NewHandler(*kubernetesClient, "some-default-namespace-name")
However, the library can access ConfigMaps in other namespaces.
Add the namespace
field into the payload, e.g.:
{
"id": "test-config-map",
"namespace": "my-namespace",
"data": {
...
}
}
Add the ?filter=
query parameter to the end of the URL.
E.g.: /api/config-map/test-config-map?filter={namespace:"my-namespace"}
Operation | HTTP method | URL | Example payload |
---|---|---|---|
Create new ConfigMap | POST | /api/config-map |
{{"id": "test-config-map", "data": {"config_value": "Hello"}}} |
Update existing ConfigMap | PUT | /api/config-map/test-config-map |
{{"id": "test-config-map", "data": {"config_value": "Hello2"}}} |
Delete existing ConfigMap | DELETE | /api/config-map/test-config-map |
None |
Find existing ConfigMap | GET | /api/config-map/test-config-map |
None |
REST call examples are also available in Postman format here. Make sure to override the {{configmap-handler}}
variable to the actual host where the application is running, e.g. http://localhost:8080
.
The functionality can be easily tested by running Minikube locally and using the out of cluster Kubernetes client configuration.