From 5c086bc52fa3a226bcf706b1f420a5d98ea377dd Mon Sep 17 00:00:00 2001 From: Patrick Spek Date: Wed, 15 Dec 2021 10:45:58 +0100 Subject: Redo most of the blog in Hugo Missing posts will have to be added later --- content/posts/2021/2021-05-13-a-new-irc-client.md | 85 +++++++++ .../posts/2021/2021-05-22-raku-on-libera-chat.md | 35 ++++ ...managing-docker-compose-projects-with-openrc.md | 194 +++++++++++++++++++++ content/posts/2021/_index.md | 3 + 4 files changed, 317 insertions(+) create mode 100644 content/posts/2021/2021-05-13-a-new-irc-client.md create mode 100644 content/posts/2021/2021-05-22-raku-on-libera-chat.md create mode 100644 content/posts/2021/2021-06-04-managing-docker-compose-projects-with-openrc.md create mode 100644 content/posts/2021/_index.md (limited to 'content/posts/2021') diff --git a/content/posts/2021/2021-05-13-a-new-irc-client.md b/content/posts/2021/2021-05-13-a-new-irc-client.md new file mode 100644 index 0000000..7003cb5 --- /dev/null +++ b/content/posts/2021/2021-05-13-a-new-irc-client.md @@ -0,0 +1,85 @@ +--- +date: 2021-05-13 +title: A New IRC::Client +tags: +- Raku +- IRC +- Programming +social: + email: mailto:~tyil/public-inbox@lists.sr.ht&subject=A New IRC::Client +--- + +The Raku programming language has a popular module for creating IRC bots, +[`IRC::Client`](https://github.com/raku-community-modules/IRC-Client). However, +it's been stale for quite a while, and one of the bots I host, +[Geth](https://github.com/Raku/geth), is having troubles on a regular basis. + +I've looked at the source code, and found a lot of neat tricks, but when +maintaining a library, I generally want clean and straightforward code instead. +To that end, I decided to just write my own from scratch. Given that [the IRC +protocol is rather simple](https://tools.ietf.org/html/rfc2812), this was the +easiest way to go about it. + +Sure enough, after a couple hours of playing around, I had something that +worked reasonably well. A few more hours a day afterwards brought me to an +`IRC::Client` that is usable in mostly the same way as the current +`IRC::Client`, to save me effort in getting my current bots to make use of it +for a few test runs. + +Geth was my main target, as I wanted it to stop from getting timed out so +often. For the past week, Geth has been running stable, without any time +out, so I think I've succeeded in the main goal. + +However, how to continue next? Since it is mostly compatible, but not +*completely* compatible, if I were to adopt `IRC::Client` from the Raku +ecosystem and push my version, many people's IRC bots would break when people +update their dependencies. There is a solution for this built into the entire +ecosystem, which is using the correct `:ver` and `:auth` (and in some cases, +`:api`) so you can ensure your project is always getting the "correct" +dependency. However, from personal experience, I know these additional +dependency restrictions are rarely used in practice. + +I hope that with this blog post, I can inform the community in time about the +changes that are coming to `IRC::Client`, so people have ample time to set +their dependencies just right to keep their projects working. Of course, the +real solution for the long term would be to make the small changes required to +use the latest `IRC::Client` again. + +For convenience sake, I've added a small number of methods for backwards +compatibility as well, though these will generate [a deprecation +warning](https://docs.raku.org/routine/is%20DEPRECATED), and will be removed in +a later `IRC::Client` release. + +There's two major changes that are not backwards compatible, however. The first +one is the removal of the ability to have a single `IRC::Client` connect to +multiple servers. This is also the easiest to remedy, by simply creating +multiple instances of `IRC::Client`. + +The second major incompatible change is how events are dispatched to plugins. +This used to be handled by going through all the plugins sequentially, allowing +one plugin to stop the dispatch to another plugin. In my new version, events +are dispatched to all plugins in parallel. This allows for faster execution, +and for multiple plugins to handle an event without having to use `$*NEXT` +(which has been removed). My main motivation is that a buggy plugin will no +longer interfere with the interactions provided by other plugins. The ordering +of your plugins will also stop being an issue to worry about. + +Geth's updates to actually use my updated `IRC::Client` module was introduced +in +[`edc6b08`](https://github.com/Raku/geth/commit/edc6b08036c8ede08afdea39fd1768655a2766aa), +and most if it was updates to the way it handled logging. The actual changes +needed to make Geth play nice were + +- [Adding the `IRC::Client::Plugin` role to `Geth::Plugin::Info`](https://github.com/Raku/geth/commit/edc6b08036c8ede08afdea39fd1768655a2766aa#diff-104b5cdb61f2aa423eb941ce32a4412b4cb814014728cae968e5aeff7dc587d2R14); +- [And to `Geth::Plugin::Uptime`](https://github.com/Raku/geth/commit/edc6b08036c8ede08afdea39fd1768655a2766aa#diff-104b5cdb61f2aa423eb941ce32a4412b4cb814014728cae968e5aeff7dc587d2R24); +- [Using `nicks` instead of `nick`](https://github.com/Raku/geth/commit/edc6b08036c8ede08afdea39fd1768655a2766aa#diff-104b5cdb61f2aa423eb941ce32a4412b4cb814014728cae968e5aeff7dc587d2R34); +- [Using `start` instead of `run`](https://github.com/Raku/geth/commit/edc6b08036c8ede08afdea39fd1768655a2766aa#diff-104b5cdb61f2aa423eb941ce32a4412b4cb814014728cae968e5aeff7dc587d2R46); +- [Using `privmsg` instead of `send`](https://github.com/Raku/geth/commit/edc6b08036c8ede08afdea39fd1768655a2766aa#diff-c388af832470886cdd4304aeb17c4c2f406ac184d33afb956b0ef8a92b69855bR57); + +The last two changes aren't strictly necessary, as there are backwards +compatibility methods made for these, but it's a rather small change and +reduces the amount of noise in the logs. + +With this, I hope everyone using `IRC::Client` is prepared for the coming +changes. If you have any comments or questions, do not hesitate to reach out to +me and share your thoughts! diff --git a/content/posts/2021/2021-05-22-raku-on-libera-chat.md b/content/posts/2021/2021-05-22-raku-on-libera-chat.md new file mode 100644 index 0000000..87ce7ff --- /dev/null +++ b/content/posts/2021/2021-05-22-raku-on-libera-chat.md @@ -0,0 +1,35 @@ +--- +date: 2021-05-22 +title: Raku is moving to Libera.chat +tags: +- Raku +- LiberaChat +- IRC +social: + email: mailto:~tyil/public-inbox@lists.sr.ht&subject=Raku is moving to Libera.chat +--- + +Earlier this week, the staff at the Freenode IRC network have resigned en +masse, and created a new network, Libera. This was sparked by [new ownership of +Freenode](https://kline.sh/). Due to concerns with the new ownership, the Raku +Steering Council has decided to also migrate our IRC channels to Libera. + +This requires us to take a couple steps. First and foremost, we need to +register the Raku project, to allow us a claim to the `#raku` and related +channels. Approval for this happened within 24 hours, and as such, we can +continue on the more noticable steps. + +The IRC bots we're using for various tasks will be moved next, and the Raku +documentation has to be updated to refer to Libera instead of Freenode. The +coming week we'll be working on that, together with the people who provide +those bots. + +Once this is done, the last step involves the Matrix bridge. Libera and +Matrix.org staff are working on this, but there's no definite timeline +available just yet. This may mean that Matrix users will temporarily not be +able to join the discussions happening at Libera. We will keep an eye on the +progress of this, and set up the bridge as soon as it has been made available. + +If you have any questions regarding the migration, feel free to reach out to us +via email (`rsc@raku.org`) or on IRC (`#raku-steering-council` on +irc.libera.chat). diff --git a/content/posts/2021/2021-06-04-managing-docker-compose-projects-with-openrc.md b/content/posts/2021/2021-06-04-managing-docker-compose-projects-with-openrc.md new file mode 100644 index 0000000..c182654 --- /dev/null +++ b/content/posts/2021/2021-06-04-managing-docker-compose-projects-with-openrc.md @@ -0,0 +1,194 @@ +--- +date: 2021-06-04 +title: Managing Docker Compose with OpenRC +tags: +- Gentoo +- OpenRC +- Docker +- DockerCompose +--- + +On one of my machines, I host a couple services using `docker-compose`. I +wanted to start/restart/stop these using the default init/service manager used +on the machine, `openrc`. This would allow them to start/stop automatically +with Docker (which coincides with the machine powering on or off, +respectively). + +I've set this up through a single `docker-compose` meta-service. To add new +`docker-compose` projects to be managed, all I need to do for `openrc` +configuration is creating a symlink, and configure the path to the +`docker-compose.yaml` file. + +The meta-service lives at `/etc/init.d/docker-compose`, just like all other +services managed by `openrc`. This file is quite straightforward. To start off, +a number of variables are set and exported. + +```sh +name="$RC_SVCNAME" +description="OpenRC script for managing the $name docker-compose project" + +# Set default values +DOCKER_COMPOSE="${DOCKER_COMPOSE:-docker-compose} $DOCKER_COMPOSE_ARGS" + +COMPOSE_PROJECT_NAME="${COMPOSE_PROJECT_NAME:-$name}" + +# Export all variables used by docker-compose CLI +export COMPOSE_PROJECT_NAME +export COMPOSE_FILE +export COMPOSE_PROFILES +export COMPOSE_API_VERSION +export DOCKER_HOST +export DOCKER_TLS_VERIFY +export DOCKER_CERT_PATH +export COMPOSE_HTTP_TIMEOUT +export COMPOSE_TLS_VERSION +export COMPOSE_CONVERT_WINDOWS_PATHS +export COMPOSE_PATH_SEPARATOR +export COMPOSE_FORCE_WINDOWS_HOST +export COMPOSE_IGNORE_ORPHANS +export COMPOSE_PARALLEL_LIMIT +export COMPOSE_INTERACTIVE_NO_CLI +export COMPOSE_DOCKER_CLI_BUILD +``` + +One of the services I use is also configured with its own `external` network. I +want it to be created if it doesn't exist, to ensure that the service can start +up properly. I do *not* want it to be removed, so I left that out. + +```sh +# Set up (external) networks +for name in "${DOCKER_NETWORKS[@]}" +do + # Create the network if needed + if ! docker network ls | awk '{ print $2 }' | grep -q "$name" + then + einfo "Creating docker network '$name'" + docker network create "$name" > /dev/null + fi + + # Expose some variables for the networks + network_id="DOCKER_NETWORK_${name}_ID" + + declare -gx DOCKER_NETWORK_${name}_ID="$(docker network ls | awk '$2 == "'"$name"'" { print $1 }')" + declare -gx DOCKER_NETWORK_${name}_GATEWAY="$(docker network inspect "${!network_id}" | jq -r '.[0].IPAM.Config[0].Gateway')" + + unset network_id +done +``` + +And lastly, there's the four simple functions to declare dependencies, +configure how to `start` or `stop`, and how to get the `status` of the service. + +```sh +depend() { + need docker +} + +start() { + $DOCKER_COMPOSE --project-directory "$COMPOSE_PROJECT_DIRECTORY" up -d +} + +status() { + $DOCKER_COMPOSE --project-directory "$COMPOSE_PROJECT_DIRECTORY" ps +} + +stop() { + $DOCKER_COMPOSE --project-directory "$COMPOSE_PROJECT_DIRECTORY" down +} +``` + +Now, to actually create a service file to manage a `docker-compose` project, a +symlink must be made. I'll take my +[`botamusique`](https://github.com/azlux/botamusique) service as an example. + +``` +ln -s /etc/init.d/docker-compose /etc/init.d/botamusique +``` + +This service can't start just yet, as there's no `$COMPOSE_PROJECT_DIRECTORY` +configured for it yet. For this, a similarly named file should be made in +`/etc/conf.d`. In here, any variable used by the service can be configured. + +``` +$EDITOR /etc/conf.d/botamusique +``` + +In my case, it only pertains the `$COMPOSE_PROJECT_DIRECTORY` variable. + +``` +COMPOSE_PROJECT_DIRECTORY="/var/docker-compose/botamusique" +``` + +And that's it. For additional `docker-compose` projects I need to make only a +symlink and a configuration file. If I discover a bug or nuisance, only a +single file needs to be altered to get the benefit on all the `docker-compose` +services. + +For reference, here's the full `/etc/init.d/docker-compose` file. + +```sh +#!/sbin/openrc-run +# Copyright 2021 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +name="$RC_SVCNAME" +description="OpenRC script for managing the $name docker-compose project" + +# Set default values +DOCKER_COMPOSE="${DOCKER_COMPOSE:-docker-compose} $DOCKER_COMPOSE_ARGS" + +COMPOSE_PROJECT_NAME="${COMPOSE_PROJECT_NAME:-$name}" + +# Export all variables used by docker-compose CLI +export COMPOSE_PROJECT_NAME +export COMPOSE_FILE +export COMPOSE_PROFILES +export COMPOSE_API_VERSION +export DOCKER_HOST +export DOCKER_TLS_VERIFY +export DOCKER_CERT_PATH +export COMPOSE_HTTP_TIMEOUT +export COMPOSE_TLS_VERSION +export COMPOSE_CONVERT_WINDOWS_PATHS +export COMPOSE_PATH_SEPARATOR +export COMPOSE_FORCE_WINDOWS_HOST +export COMPOSE_IGNORE_ORPHANS +export COMPOSE_PARALLEL_LIMIT +export COMPOSE_INTERACTIVE_NO_CLI +export COMPOSE_DOCKER_CLI_BUILD + +# Set up (external) networks +for name in "${DOCKER_NETWORKS[@]}" +do + # Create the network if needed + if ! docker network ls | awk '{ print $2 }' | grep -q "$name" + then + einfo "Creating docker network '$name'" + docker network create "$name" > /dev/null + fi + + # Expose some variables for the networks + network_id="DOCKER_NETWORK_${name}_ID" + + declare -gx DOCKER_NETWORK_${name}_ID="$(docker network ls | awk '$2 == "'"$name"'" { print $1 }')" + declare -gx DOCKER_NETWORK_${name}_GATEWAY="$(docker network inspect "${!network_id}" | jq -r '.[0].IPAM.Config[0].Gateway')" + + unset network_id +done + +depend() { + need docker +} + +start() { + $DOCKER_COMPOSE --project-directory "$COMPOSE_PROJECT_DIRECTORY" up -d +} + +status() { + $DOCKER_COMPOSE --project-directory "$COMPOSE_PROJECT_DIRECTORY" ps +} + +stop() { + $DOCKER_COMPOSE --project-directory "$COMPOSE_PROJECT_DIRECTORY" down +} +``` diff --git a/content/posts/2021/_index.md b/content/posts/2021/_index.md new file mode 100644 index 0000000..1287d56 --- /dev/null +++ b/content/posts/2021/_index.md @@ -0,0 +1,3 @@ +--- +title: 2021 +--- -- cgit v1.1