[stork-users] Stork installation feedback
Slawek Figiel
slawek at isc.org
Wed Aug 30 10:40:00 UTC 2023
Hello Ben!
Thank you very much for your report. It will allow us to improve the
user experience of our Docker-related solutions.
Currently, we are developing the official Docker images with Kea and Kea
+ Stork. You can find them in the
https://gitlab.isc.org/isc-projects/kea-docker repository. If you
already have some experience with containerizing Kea, we will be honored
if you decide to contribute.
I have forwarded your report to the team that is working on this repository.
Answering to your points in the feedback:
> [1.1] No package requirements are listed, though apparently curl,
bash, and sed are needed. Should specify.
You are right. We will add the list of dependencies in #1147.
> [1.2] (...) Apparently CloudSmith does not even host Alpine binaries
for Stork. Is the documentation in error or will Alpine binaries be
added in the near future?
We have added support to prepare Alpine packages for the Stork build
system, and we were planning to publish them on CloudSmith.
Unfortunately, due to technical reasons, the packages were rejected
because their metadata was incomplete. Currently, we don't have enough
time to solve the problem. The mentions about the installation script
for Alpine will be removed in #1137.
> [2] (...) This required a few dependencies not listed in the
documentation.
The Stork build system is dynamically developed, so the list of
necessary dependencies may often be changed. To list the packages that
must be installed manually on your operating system, you should call the
`rake check:dist` command (for checking the dependencies related to
preparing distribution binaries and packages).
> [3] (...) Hence, a monolithic container containing all was required.
In my opinion, this is undesirable, at least for my type of setup. Other
connectivity options are desirable.
Stork Agent detects the Kea and BIND 9 services by listing the currently
running processes. It is convenient because users don't need to
configure the Stork agent and provide the location of the Kea DHCP
daemon and CA or BIND 9 daemon. But as you noticed, in the case of
Docker deployment, it requires installing all components in a single
container and additionally running Stork and Kea as the same user.
Kea CA is able to communicate with the Kea DHCP daemons only by the Unix
sockets due to security reasons. The HTTP connections would require any
authentication solution (e.g., TLS certificates). It would complicate
the configuration. But there are some early plans to unify Kea DHCP
daemon and CA, so it may change in the future (rather far future).
> [4] Initialization using current PostgreSQL required appending the
following
Sure, I opened #1148 to address this issue.
> [5] (...) Could another environment variable be introduced to
distinguish between the Stork Agent hostname as called by Stork Server
and what Stork Agent binds to?
I opened #1149 to address the problem.
>
After resolving these problems Stork is up and running. It looks like it
will be very useful. Kea functionality is very good. I hope to see more
BIND functionality added in the future.
I'm glad to hear that you were able to deploy Kea and Stork in your
environment and that you have found it useful. Thank you again for your
feedback.
Regards,
Slawek
On 30/08/2023 05:40, Ben Monroe wrote:
>
> Hi all. I am new to the list and Stork, though I have been using Kea
> for a number of years. I recently setup Stork but ran into several
> issues that I hope can be reported as constructive feedback.
>
> For the last few years I have been running BIND and Kea in containers.
> This has worked well, though it was a little fragile and required some
> administration after an unplanned power outage. This gave me an
> opportunity to revisit this setup. I decided to re-implement this as a
> Kubernetes cluster, which gave me an opportunity to implement Stork.
>
> Note: I am not interested in debating whether this should be run as a
> container. It suits my environment and use-case. For those wondering,
> I am using MetaLB for load balancing and Longhorn for distributed
> storage. As for Kea itself, it is located on a separate VLAN with DHCP
> relay on switches forwarding broadcasts for VLANs that it services.
>
> [1] The documentation has an "Installing on Alpine" section. I spent a
> while trying to get this to work but ran into multiple problems.
>
> [1.1] No package requirements are listed, though apparently curl,
> bash, and sed are needed. Should specify.
>
> [1.2] Section 2.5.1.3 indicates to curl
> https://dl.cloudsmith.io/public/isc/stork/cfg/setup/setup.alpine.sh'
> <https://dl.cloudsmith.io/public/isc/stork/cfg/setup/setup.alpine.sh'>.
> This returns "Not found". A bit of investigation indicated to use
> 'bash.alpine.sh <http://bash.alpine.sh>' and pipe it to bash instead.
>
> [1.3] Finally, trying to add the Stork server package results in the
> following error:
>
> / # apk add --allow-untrusted isc-stork-server
>
> ERROR: unable to select packages:
>
> isc-stork-server (no such package):
>
> required by: world[isc-stork-server]
>
> / #
>
> Apparently CloudSmith does not even host Alpine binaries for Stork. Is
> the documentation in error or will Alpine binaries be added in the
> near future?
>
> Links:
>
> https://stork.readthedocs.io/en/latest/install.html#installing-on-alpine
>
> https://cloudsmith.io/~isc/repos/stork/packages/
>
> [2] I am using Alpine as it is typically the most light-weight for
> building containers. So I compiled my own build. This required a few
> dependencies not listed in the documentation. For reference, I will
> include them here (along with a Docker step).
>
> docker run -it --rm alpine:latest /bin/sh
>
> apk update
>
> apk add git ruby go npm protoc python3 openjdk17 openssh
>
> gem install rake
>
> git clone https://gitlab.isc.org/isc-projects/stork
>
> cd stork
>
> rake build
>
> rake install:agent
>
> rake install:server
>
> Following this, copy the output in stork/dist to an external location,
> create a dockerfile copying in Stork Server and upload to an image
> repository. Repeat for Kea and add in the Stork Agent.
>
> [3] Stork Agent and all Kea components (kea-ctrl-agent, kea-dhcp4,
> kea-dhcp6, and kea-dhcp-ddns) all need to be installed together.
> Previously I ran each Kea component in separate containers. However,
> 1) Stork Agent must reside with Kea CA, and 2) Kea CA can only connect
> to DHCP4, DHCP6, and DDNS via Unix sockets. Hence, a monolithic
> container containing all was required. In my opinion, this is
> undesirable, at least for my type of setup. Other connectivity options
> are desirable.
>
> [4] Initialization using current PostgreSQL required appending the
> following:
>
> GRANT ALL ON SCHEMA public TO stork;
>
> [5] Configuration of STORK_AGENT_HOSTrequired special handling. Within
> the Kea container, I do not know what the IP address will be. Setting
> it to 0.0.0.0 allows Stork Agent to bind, but Stork Server will
> naturally never be able to connect to this. Stork Server communicates
> with Kea via a ClusterIP service pointing to Kea pod(s). However,
> within the Kea pod, Stork Agent cannot bind to this ClusterIP service.
> In the end, I had to resort to DNS trickery: I let the Stork Server
> pod resolve the ClusterIP service name as normal, though within the
> Kea pod this ClusterIP service resolves to 0.0.0.0, which is
> sufficient for Stork Agent to bind. (For those interested, I used
> hostAliasesin the deployment YAML to override the pod DNS.) Could
> another environment variable be introduced to distinguish between the
> Stork Agent hostname as called by Stork Server and what Stork Agent
> binds to?
>
>
> After resolving these problems Stork is up and running. It looks like
> it will be very useful. Kea functionality is very good. I hope to see
> more BIND functionality added in the future.
>
>
> Best regards,
>
> Ben Monroe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/stork-users/attachments/20230830/85e5d64d/attachment-0001.htm>
More information about the Stork-users
mailing list