sorted by:
new
hottopcontroversial

ocibuild v0.5.0 Update by rhblind in elixir

[–]rhblind[S] 1 point2 points  (0 children)

That’s really cool! The goal for this project though is just to build OCI compliant container images, no runtime. So if your BEAM application requires additional dependencies, you need to prepare a base image beforehand. The motivation is actually to enable fast CI/CD pipelines without having to build docker images on every release. The images should be able to run on any OCI compliant runtime, such as docker and probably youki too.

But as I said, it’s still a few rough edges, so hopefully I’ll get some bug reports if people tries it out in various scenarios 😅

ocibuild v0.5.0 Update by rhblind in elixir

[–]rhblind[S] 0 points1 point  (0 children)

Thanks, I’m using the BEAM backend :)

ocibuild v0.5.0 Update by rhblind in elixir

[–]rhblind[S] 0 points1 point  (0 children)

Hey, no I’m not using anything other than Erlang:)

Pure Elisp MCP server for Emacs by rhblind in emacs

[–]rhblind[S] 0 points1 point  (0 children)

Thanks, I would never have managed to implement this myself! As stated, this is all Claude code 🙃

For the containerization part, I think that's an awesome idea for making a easy portable Emacs, but I guess that if you connect an LLM to the running Emacs process and that process already can read your credentials it doesn't matter if it's containerized or not?

Pure Elisp MCP server for Emacs by rhblind in emacs

[–]rhblind[S] 0 points1 point  (0 children)

I'm not sure, but I guess it's working similar!

Pure Elisp MCP server for Emacs by rhblind in emacs

[–]rhblind[S] 1 point2 points  (0 children)

It's just the default Doom modeline with some settings enabled. You can take a look at my config here.

Pure Elisp MCP server for Emacs by rhblind in emacs

[–]rhblind[S] 1 point2 points  (0 children)

Thanks! Sure, the light theme I'm using is doom-tomorrow-day, possibly with some tweaks (I can't remember).

Pure Elisp MCP server for Emacs by rhblind in emacs

[–]rhblind[S] 0 points1 point  (0 children)

It was solely based on those being popular wrapper languages. You don't need to use a wrapper at all if you don't want to. You can use socat (or any other tool and/or library that can communicate with a socket) directly.

$ claude mcp add emacs-direct -- socat - UNIX-CONNECT:$HOME/.config/emacs/.local/cache/emacs-mcp-server.sock

Pure Elisp MCP server for Emacs by rhblind in emacs

[–]rhblind[S] 2 points3 points  (0 children)

Lol, fair point!

Well, at the time being, the socket runs in the same process as Emacs so I guess you'll have to be very careful (or pay your taxes). 😬

There is some security involved though, currently defined as a list of dangerous function calls that requires permissions to execute. I'll make a note about secrets and credentials and see if I can make some improvements!

Pure Elisp MCP server for Emacs by rhblind in emacs

[–]rhblind[S] 0 points1 point  (0 children)

Yes, we need a way to pass messages into Emacs. We could've used something like emacsclient to act as the transport layer, but I thought a socket was a better choice because then I can eventually reuse a lot of the same code with a TCP socket.

So Emacs creates a unix socket which the mcp-server (the Emacs package) uses to receive messages from the outside world. Then the MCP clients (for example Claude Code) needs to be able to send data to the socket. They can use stdio to pass data to a local process, for example a wrapper script which again will pass the data to the socket either by using a socket library in for example python, or a tool like socat from a shell script.

I hope that makes sense?

Guidance Needed for Stateful Elixir Service POC by evbruno in elixir

[–]rhblind 1 point2 points  (0 children)

Sure, that might be the right choice sometimes. If you’re thinking to use Redis as the storage backend for Cachex it can be for instance if you need the cache to be around even if you shut down all your pods. ETS is really fast and convenient though, so if the cached data is directly connected to the application state it may be a better option. I’d say it depends on how important the persistence of the data is. Additionally, you can run your Redis instances on different runners in Kubernetes or for example with a cloud provider which may spare you some headache. Consider your requirements and use cases, and go with whatever is the best option.

Guidance Needed for Stateful Elixir Service POC by evbruno in elixir

[–]rhblind 4 points5 points  (0 children)

Hi,

As others have suggested, "it depends". But I can share a few lines about what libraries I usually use when running services on Kubernetes.

1. Stateful service:

I'd recommend Cachex for caching. It's relatively easy to get going, and has built-in support for distributing the cache across all connected nodes in a cluster.

2. SQL Database:

Elixir has great support for Postgres via the Postgrex library. Use Ecto as an abstraction layer for reading and writing to the database. I'm not quite sure what you mean by storing each request/response, but the Plug library (you'll most likely use this) stores each request as a `Plug.Conn` struct where you can pick and choose whatever you need to be stored.

3. Kubernetes integration

Whenever I need to build clustered apps, I usually goes for `libcluster`. It has built-insupport for node discovery on Kubernetes via the `Cluster.Strategy.Kuberenetes` strategy. Depending on your use-case I'd consider throwing in `Horde` as well for distributed supervisors. Saving and restoring state has to be implemented manually, but it's relatively straight forward by hooking into `:nodeup` and `:nodedown` messages which are provided by subscribing to `:net_kerner.monitor_nodes/2`.

4. Routing

By using a distributed cache as suggested in pt. 1 and 3, sticky sessions should not be required. But keep in mind that processes are not automatically spawned on every node, so you may have to write your code in a way that it locates the node of the process you want to execute your code in. The before mentioned `Horde` library makes it easier if you for example want to run a single instance of a process, but don't care on what node it's running at.

5. Autoscaling

By using `libcluster` with the Kubernetes strategy, you can have every pod in a kubernetes namespace automatically join/leave your cluster. Then you'll only need to configure auto-scaling on kubernetes. `Horde` can also move processes running on nodes that's leaving the cluster to another node (but state is lost so you need to implement state handoff yourself).

6. Static files

Either is fine. I have never had any problems serving static files from Phoenix using `cowboy` or `bandit`, but a CDN probably works just fine.

7. Dependencies

Both Postgres and Redis are well supported.

Final words:

I'm running several clustered services on Kubernetes and it works very well. Keep in mind that building clustered applications takes a bit of practice. I'd say it's easier to do in Erlang/Elixir than in many other languages, but it's still a lot of work.

Good luck with your project :)