For everyone else confused too…think moose in this context is probably this: https://mooseframework.inl.gov/
Maybe this is the greybeard in me, but I first thought about https://metacpan.org/pod/Moose, and catalyst (http://catalyst.perl.org/)
Self-Hosting Moose with Docker Compose, Redis, Temporal, Redpanda and ClickHouse
11–17 of 17 posts
Re: Self-Hosting Moose with Docker Compose, Redis, Temporal, Redpanda and ClickHouse
#12Re: Self-Hosting Moose with Docker Compose, Redis, Temporal, Redpanda and ClickHouse
#13How Moose compares to more traditional ELT data pipeline orchestration frameworks, like Airflow, Dagster, dbt, DuckDB for transformation steps.
I think one of the reasons to use an orchestration framework is integations.
Re: Self-Hosting Moose with Docker Compose, Redis, Temporal, Redpanda and ClickHouse
#14You don't publish a ready-made image anywhere? That would be easier to spin it up without installing locally moose first. Kind of defeats the purpose of Docker Compose recipe.
And those ports bindings, is it really necessary to expose it on 0.0.0.0 by default.
Re: Self-Hosting Moose with Docker Compose, Redis, Temporal, Redpanda and ClickHouse
#15How Moose compares to more traditional ELT data pipeline orchestration frameworks, like Airflow, Dagster, dbt, DuckDB for transformation steps. I think one of the reasons to use an orchestration framework is integations.
Hi!
We are built on top of them. Right now the techs above are what’s backing the implementation but we want to add different compatibilities. So that you can eventually have for example airflow backing up your orchestration instead of temporal.
You can think of moose as the pre-built glue between those components with the equivalent UX of a web framework (ie you get hit reloading, instant feedback, etc…)
Re: Self-Hosting Moose with Docker Compose, Redis, Temporal, Redpanda and ClickHouse
#16You don't publish a ready-made image anywhere? That would be easier to spin it up without installing locally moose first. Kind of defeats the purpose of Docker Compose recipe. And those ports bindings, is it really necessary to expose it on 0.0.0.0 by default.
Not sure if this is what you are asking about, so if I misread feel free to correct me. You don’t have to install moose first on the deployment machine, in the tutorial I go through that to generate a dummy moose application to be deployed.
It is the same idea as a nextjs application you deploy through docker, you have your application and then you build your docker container that contains your code, then you can deploy that.
I tried to limit the port bindings, we usually expose moose itself since one of the use case is collecting data for product analytics from a web front end, which pushes data to moose. And then usually people want to expose rest apis on top of the data they have collected. The clickhouse ports could be fully closed, this was an example of if you want to connect PowerBook to it