1/21/2024 0 Comments Add port to git clone commandI’m very open to critics and would really like some feedback here. I’m not at all familiar with distributed systems so my approach might seem foolish. We’d have to store the Fly volume ID instead of the region and keep trace (CRDT) of volume assignment during deployment and cluster changes. ![]() Now this solution is only partially pleasing because it does not support multiple instances in the same region. With a different distribution strategy Git commands are routed to the right node based on the repository region. We use the Fly-Region HTTP header to assign the region and init the repository there. So let’s say a user creates a new repository via the Web frontend. Instead my idea is to assign a specific region to a repository (additional :region field on Ecto schema) on creation and use the region to retrieve the right node in the cluster. I don’t want to deal with handing off repositories and clone their respective data to other nodes when my cluster changes (auto-scaling etc.). I think having a hashring for distributing repositories across nodes is not the right strategy here. In order to deploy this setup on Fly, I still miss a few things: taking volumes and regions into account. This includes the web frontend, GraphQL API and Git transfer protocols implementations(HTTP, SSH). So any Git related command within the cluster are routed to the right node. The core component is the GitAgent module, a dedicated Erlang process allowing multiple processes to manipulate a Git repository simultaneously: alias GitRekt.GitAgent Have you figured out how you’d make clustering work with git repos on different disks in different regions? It would be very cool to have my git repositories somewhere close to me. Currently the setup is quite simple (see commit Mess around with fly.io) and hasīut it would be nice to provide a multi-node environment running in different regions. I’ve tried to use the experimental allow_public_port without success (IPv6 only?).Ĭurrently, I’m using port 10022 but it’s somehow cumbersome to use on the client side: git clone git clone like to start experimenting with the distributed aspect of fly.io soon. In my case, I’d like to use port 22 for Git client commands over SSH. ![]() Now I’ve seen that only a handful of ports are allowed to be exposed. It implements (in Elixir) the Git transfer protocol and provides support for both HTTP and SSH ( :ssh.daemon/3) transport protocols. You can check the GitHub project or the demo running on fly.io here: It is very self-contained and does not require much dependencies (solely libgit2 and openssh-ssh-keygen). My project is a GitHub clone mostly written in Elixir (NIFs written in C for working with libgit2). The experience has been delightful so far and I’m exited about the distributed possibilities fly.io offers and how it seems to naturally fit with the BEAM world. ![]() With the help of the “Elixir Getting Started Guide” I’ve managed to deploy my project without much hassle. Hi, I’ve heard of fly.io quite recently and instantly wanted to give it a try.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |