upgrade docker-compose file draft
Hi,
It was possible to use the new features of docker-compose. Please find a sample docker-compose.yml attached:
docker-compose.yml (8.08 kB)
Regards,
Mustafa
KajMagnus @KajMagnus2018-10-23 08:10:43.578ZHi Mustafa thanks for the message and the file :- ) Sorry for the late reply.
This setup works fine for you? And ... if you do
git fetch originto download a new version of Talkyard, then, since in the docker-compose.yml file you're using the latest Docker tag (since not tag explicitly specified), I'm thinking that after a build and restart, you'll be running the latest Talkyard version? (Is that how things seem to work for you?)
Someone wants to run Talkyard behind Traefik (he mentioned here), and I'm thinking maybe he'd be interesting in seeing how you have configured this docker-compose file. Maybe I can remove the private parts of your compose-file, post here in this topic for you to inspect (so you'll see I didn't forget to remove something), ...
... and then we can show the only-Talkyard-related parts of your config for him, ... and maybe that'll give him ideas about how to configure Talkyard behind Traefik?
When I release new versions of Talkyard, I run this script: s/build-and-release.sh. Talkyard images then get pushed to a Docker repository named debiki, and that's the repo everyone uses by default, when they install Talkyard as described in the readme in https://github.com/debiki/talkyard-prod-one, ... which b.t.w. has this Docker-Compose file: talkyard-prod-one docker-compose.yml
Can I ask what's the reason you're building your own images, rather than using the already-built ones available in the above-mentioned debiki repository? (And if my documentation is a bit unclear, and you didn't know about those images, that'd be interesting to hear too :- ))
- MMustafa Kuscu @mcku
Hi @KajMagnus,
It may be a bit off topic but.. here is my life story.
My motivation was to try to understand before using it. I was thinking that if it was possible to integrate from the source, it would be possible to extend it in the future in some way. One other reason is that my project is also based on play framework. And this may be an opportunity for me to compare my project and improve any of my project's shortcomings.
My wish is to build the server's docker image through sbt-native-packager. Therefore versioning is not there as of yet. The other parts like redis and nginx are kind of 'commodity' components that should not complicate the setup. Also, I prefer to have a release workflow such that one sbt release builds both the client and the server, coherently versioned. If possible, one should investigate merging the models by using ScalaJs with react or binding.scala. I like the binding.scala approach because it is very lightweight, fast and totally eliminates the need for a big library like react. It is very easy to replicate redux-like behavior on binding.scala (https://github.com/ThoughtWorksInc/Binding.scala). It is very lightweight and of great utility.
For the Traefik part, I don't know, but nchan might be an issue. In my setup I have not fixed nchan yet, therefore pub-sub does not work yet.
Other than that, I am respectful to the GPL and the compose file is public already, as an attachment to this post. If any more info is needed that is fine.
Finally, I should admit that for some reason I have noticed the existence of 'build-and-release.sh' script after I was half way ahead. :)
KajMagnus @KajMagnus2018-11-05 15:56:26.903ZOk thanks for the info & explanation :- ) Sorry for the late reply, ... I felt I had some deadlines last week so I was coding & coding & code-reviewing because of that.
Interesting to hear about Binding.scala. Apparently more light-weight than React.js. It seems as if it might be better than React.js? however I think the Scala.js runtime is like 100 kb ?, ... which means Scala.js + Binding.scala is sill more kb than React.js? Hmm. (Anyway, porting to a new lib, is (I would guess) like 2 - 10 months work, no time for that :- ) )
Actually, tying this project much closer to the Java ecosystem, makes me a bit nervous. To me, Oracle is unpredictable, and Java is a little bit risky. What's going to happen in the future, now when Oracle supports new versions of Java 11, 12, 13 etc only for half a year. And how will this affect the JVM and maybe Scala. Also, the JVM uses rather much memory. If Talkyard's app server, and the full text search engine, had instead been written in Rust, then the whole Talkyard stack, would need maybe only 200 MB memory. Now instead Talkyard needs like 2 GB, because of the JVM.
... Long term, thinking maybe 5 years into the future, it'd feel safer to not be too dependent on Oracle and JVM things. And instead use things like Gulp and Webpack etc, for transpiling Javascript. Also I think this makes it simpler for not all, but most people, to contribute. Because more people are familiar with Javascript build tools, than with SBT. ... And maybe it turns out that some parts of the app server, would be better of if written in Rust or Lua, as Nginx plugins, or maybe in Golang as Traefik plugins, — then, one could do those tech stack changes, by editing maybe a language agnostic Makefile.
Hmm I'm thinking the build-and-release.sh script is hard to find and that I haven't documented this at all. o.O
Right now I have in mind to add a Makefile. Then, the plan is that one just types:make docker-imagesand that'll do everything.
Here's a topic about that: https://www.talkyard.io/-159/how-do-you-want-to-build-and-upgrade-yourselfAnd I'm going to look at the Compose file you posted, and create a sample compose file, which people can use to add Talkyard to their own Compose stack, or Swarm cluster. Here's a topic about that: https://www.talkyard.io/-163/k8s-swarm-traefik-and-talkyard