[HN Gopher] Spin up your development background processes with ease
       ___________________________________________________________________
        
       Spin up your development background processes with ease
        
       Author : philo01
       Score  : 50 points
       Date   : 2022-12-28 11:54 UTC (11 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | throwawayacc3 wrote:
       | Am I the only one who uses a development Nomad cluster to solve
       | the exact same problem? Not sure what this and other tools
       | suggested in the comments here have over Nomad.
       | 
       | Nomad can schedule anything: random JAR files, scripts,
       | Docker/Podman containers, firecracker VMs, you name it.
        
       | lionkor wrote:
       | the only advantage over docker that I see is that it doesnt
       | require the overlay fs stuff docker has, but the downside of this
       | is that it doesnt keep its own state. It seems to use system
       | state, such as any global configuration, caches, etc.
       | 
       | I prefer docker compose, simply because its fully reproducible,
       | no matter where I am, and sets up all the tools it uses.
       | 
       | This tools looks like it still requires you to install your
       | tooling - that screams like it will break if you have different
       | distros you run this on, with different versions of tools, etc.
        
         | philo01 wrote:
         | Agree, it all depends on your use case. Docker is amazing for
         | projects that require services that are difficult to install,
         | configure and maintain on your main OS.
         | 
         | Porter is ideal for those already running these services on
         | their main OS and just need something to run and manage these
         | services more easily.
        
       | anthlax wrote:
       | I was excited about this because I use docker-compose to run a
       | service written in Rust. The final command of the container is
       | "cargo watch -x run" and the compiles take 1-2 minutes per hot
       | reload. Porter solved this by completely sidestepping images, but
       | I'm still considering if this is worth having the user install
       | cargo on their host machine (in the case of porter) and give up
       | hermetic development. Not sure yet, but thanks for this tool!
        
         | philo01 wrote:
         | I think it's worth installing software on your OS if your
         | situation allows for it. I mostly use PHP and NodeJS, which are
         | easy to manage with tools like Laravel Valet or nvm. I've been
         | doing this for years and love it. I can imagine that if you
         | have various difficult services to install and maintain on your
         | main OS, using Docker is a more convenient solution.
        
       | moojd wrote:
       | This is cool. I've been looking for something like this to pair
       | with my nix env. Docker makes process management and logging in
       | the dev environment so easy, but between the performance issues
       | and abstraction leaks when jumping back and forth between native
       | containers on linux and virtual machines on macos we gave up and
       | started using nix to handle the reproducibility of our dev
       | environment. The only thing I miss is the ease of
       | process/service/log management. If anyone has any other solutions
       | I would love to hear them.
        
         | philo01 wrote:
         | Thanks! Feel free to submit some feature requests to the GitHub
         | repo and I'll see what I can do to further ease the process of
         | service and log management.
        
         | vhodges wrote:
         | https://evilmartians.com/chronicles/introducing-overmind-and...
         | 
         | Devenv.sh is using these (out of the box)
        
       | jljljl wrote:
       | Really cool, love the idea of managing background services for
       | your dev environment, without having to use Docker Compose.
       | 
       | We've been working on a similar workflow with Devbox
       | (https://jetpack.io/devbox), using Nix to install and run dev env
       | services
        
       | Karellen wrote:
       | What's the advantage of using this over systemd user services?
       | 
       | https://wiki.archlinux.org/title/Systemd/User
       | 
       | Again, services are configured with short text-based
       | configuration files.
        
         | philo01 wrote:
         | Good question, I think there are many different approach on
         | solving running multiple services. So it boils down to what you
         | need, and what works for you. One advantage might be the ease
         | of use. Using Porter you don't need to know anything about
         | Supervisor, systemd or other more technical implementations.
         | Porter abstracts away these things so you only have to write a
         | simple .yml file.
        
           | Karellen wrote:
           | > Using Porter you don't need to know anything about
           | Supervisor, systemd [...]
           | 
           | Using systemd you don't need to know anything about Porter.
           | 
           | > One advantage might be the ease of use. [...] Porter
           | abstracts away these things so you only have to write a
           | simple .yml file.
           | 
           | Is the systemd unit file really that much more complex? The
           | example `mpd` service file might take more lines than the
           | equivalent Porter .yml snippet, but the DOS/Windows 3-era
           | ".ini" file format isn't exactly rocket surgery, and there's
           | only one kinda weird bit of boilerplate
           | ("WantedBy=default.target") that isn't immediately obvious
           | why it's there. Other than that, the systemd config for a
           | simple service is, well, simple. (At least, it looks that way
           | to me.)
           | 
           | https://wiki.archlinux.org/title/Systemd/User#Example
           | 
           | Yeah, there's a lot of complexity you can add with systemd
           | units, but only if you have complex use-cases that need it.
           | As far as I can tell, the only alternative to "Yeah, there's
           | a config option for that, but it can take a bit of reading to
           | find out its name" is "No, you can't do that, sorry".
           | 
           | As Alan Kay's classic adage goes, "simple things should be
           | simple, complex things should be possible" :-)
        
       | phpfour wrote:
       | I have started using this immediately as I saw the release tweet
       | - solves a real problem for me whenever I am working on a project
       | that doesn't use Docker. Good stuff!
        
         | philo01 wrote:
         | Thanks! That's great to hear!
        
       | aarondf wrote:
       | I'm excited for this tool. I don't use Docker so something like
       | this is going to make my life much easier. I like the idea of
       | being able to hop between projects and start all the processes I
       | need for that project with one command.
        
         | philo01 wrote:
         | Thanks Aaron! That's great to hear!
        
       | erulabs wrote:
       | If you want to take the next step past docker-compose, I strongly
       | recommend Skaffold instead of moving backwards to supervisord.
        
         | philo01 wrote:
         | Good tip! I haven't heard of Skaffold but it looks like an
         | interesting alternative. Skaffold seems to offer a great amount
         | of features but it might be a steep learning curve for
         | beginners. Porter is not meant to be a replacement for docker-
         | compose, it's more focused towards those who don't use Docker
         | and want an easy way to run certain processes.
        
       | pxc wrote:
       | I've done something similar with Nix and supervisord before. On
       | the one hand, I think this kind of simplified config format can
       | be nice for teams who don't want to have to contend with the
       | process supervisor in all its complexity. On the other,
       | supervisord is pretty simple already.
        
         | philo01 wrote:
         | Good point, I think there are many approaches to solving this
         | problem, and every approach having pros and cons. I'm adding
         | some additional features like auto restart when files are
         | modified but overall I agree that this simplified config format
         | can be nice for teams who don't want to have to contend with
         | the process supervisor in all its complexity.
        
       | brunno wrote:
       | This looks like a good alternative to Foreman
       | (https://ddollar.github.io/foreman/). Do you know about it? What
       | advantages do you think Porter has over it?
       | 
       | Congratulations on the cool project.
        
         | philo01 wrote:
         | Thanks! After I started building and sharing my progress on
         | Twitter some did suggest foreman. I just took a quick look and
         | I think Porter is a bit easier to use because of the porter.yml
         | file you can add to every project. Which may read a bit easier
         | compared to the procfiles. One or two other advantages could be
         | the interval restart feature, where you can restart services
         | automatically after a certain interval (useful for unstable
         | services). The second advantages is something I'm working on at
         | the moment, where you can define processes to restart if
         | certain files have been modified.
        
       | valyagolev wrote:
       | amazing, I only wish for the VS Code integration
        
         | philo01 wrote:
         | Thanks! You can use the build-in terminal VS Code provides to
         | run any of the Porter commands. What would you like to see in a
         | native VS Code extension?
        
           | valyagolev wrote:
           | I was looking for an extension to do the following: when I
           | open a project (and maybe press a status bar button), it runs
           | all the processes I need (from the config in the root of the
           | project) and streams their logs in separate terminals (so I
           | can see those logs immediately); when I close the projects,
           | all of this gets shutdown
        
       | philo01 wrote:
       | Porter is a command-line interface (CLI) tool that makes it easy
       | to run background services by adding a few lines to a
       | configuration file. These services are managed by Supervisord, a
       | process control system that ensures that all processes are kept
       | up and running. With Porter, you don't have to manually start and
       | manage background services in multiple terminal tabs. Instead,
       | you can simply use the porter command to manage all of your
       | services in a single place.
        
       | PufPufPuf wrote:
       | Does this have any advantages over Docker compose? It does not
       | require Docker, of course, but the reproducibility is going to be
       | much lower.
       | 
       | Also, why would you write a tool like this in PHP?
        
         | philo01 wrote:
         | I don't think it has many advantages over Docker compose
         | besides maybe the auto restart option and I'm working on adding
         | file monitoring as well, so you can set files or directories to
         | monitor and once chances occur the service restarts. I don't
         | use Docker locally myself and wanted to have a solution for
         | making it easier to manage background processes and not having
         | to spin up five shells.
         | 
         | Why I wrote a tool like this in PHP is simple, I love PHP and
         | I'm a big fan of the ecosystem / community.
        
       ___________________________________________________________________
       (page generated 2022-12-28 23:02 UTC)