This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-30
Channels
- # aws (1)
- # bangalore-clj (1)
- # beginners (73)
- # boot (13)
- # cider (3)
- # clara (19)
- # cljs-dev (33)
- # cljsrn (37)
- # clojure (177)
- # clojure-dev (13)
- # clojure-gamedev (1)
- # clojure-italy (10)
- # clojure-nlp (1)
- # clojure-russia (1)
- # clojure-spec (64)
- # clojure-uk (128)
- # clojurescript (177)
- # core-async (23)
- # cursive (5)
- # datascript (13)
- # datomic (20)
- # devops (49)
- # emacs (13)
- # graphql (5)
- # hoplon (13)
- # keechma (1)
- # leiningen (3)
- # liberator (4)
- # lumo (2)
- # off-topic (11)
- # om (19)
- # om-next (3)
- # onyx (6)
- # re-frame (13)
- # reagent (14)
- # ring-swagger (7)
- # rum (2)
- # spacemacs (7)
- # unrepl (1)
- # untangled (23)
- # vim (8)
- # yada (1)
@devn "make an uberjar, make sure the java binary exists on the server" is most of it for me
@noisesmith what about jvm options? Do you run an nrepl server? If it's a web service do you use tomcat, jetty, netty? Do you use jmx monitoring? What logging deps? Why?
I use the clojure built in socket server, because you can just start it with a command line arg to the vm
I guess I just mean to say: there would be value in a review of monitoring, deployment options and techniques
the technique is almost always: put an uberjar on a server. The rest of the stuff about tuning and library choices are interesting though, but that is as much about dev as deployment
it has to do with what your app is trying to do. Though I welcome new insights about logging and monitoring, I never feel like those are working as well as they should (maybe that is universal?)
@noisesmith I don't know that I agree fully. Yes there are decisions to be made w/r/t dev, but for someone who just wants to deploy a webapp there's no reason why there couldn't be a well-documented suggestion. Not every problem is novel.
then use luminus
it makes most of those choices for you
clojure deployment is mostly identical to java deployment, which has a lot of existing expertise and info
arachne is pretty unformed still isn't it?
but it gives you a jar
and you run that jar the same way you would any java jar
any differences from java are dev time differences, not deployment differences
clojure is a java library that supplies a main entry point that compiles bytecode
I'm saying that there's nothing about clojure that requires different strategies for deployment than java would
clojure gives you a jar, you use a jvm to run that jar
optionally you can integrate clojure with things like containers or process controllers like jsvc
but you do that as part of app development, it's not a deployment task
it's not because ruby uses different libraries
and has a weird runtime
those things are not true of clojure
clojure's runtime is a jvm, clojure's deps are bundled in a single jar just as they would be with java
clojure literally runs in any container or deployment strategy that runs java, as long as your machine has the resources to handle it - I haven't seen clojure specific deployment issues in my years of using clojure in production, other than some command line flags that you might want to tune differently
None of that really matters if people don't feel like there's a simple narrative for deploying basic clojure apps.
1) make uberjar 2) do the same thing to the uberjar you would do with java jars
I would be interested in seeing more documentation and walk throughs that are targeted to clojure, but I think the reason it doesn't exist is because the story is the same as another one that is very well documented
but it does mean that they can be without issue
or, nearly without- there's the rare corner case
I think we'd be better off if people stopped doing things that were clojure specific and stuck to existing jvm stuff actually
I'm not talking about writing java code, I'm talking about using the tooling and ops utilities around the jvm
only to make them worse, as far as ops is concerned
cheers