Clojurians Log v2

Why isn't there a better story for clojure deployment best practices?

Seems like something the community should work on

I would be happy to be involved

@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

/me checks on Arachne

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?

Clojure is young. Nothing is set in stone.

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 not sure what we're arguing about

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

Imagine I told you ruby deployment is the same as C.

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

I don't disagree with you, but can we agree the story could be better?

Clojure being on the JVM does not automatically mean all JVM customs are observed.

but it does mean that they can be without issue

or, nearly without- there's the rare corner case

I think it's a weak story

It can be true, but it's weak

I think we'd be better off if people stopped doing things that were clojure specific and stuck to existing jvm stuff actually

JVM or Java?

I'm not talking about writing java code, I'm talking about using the tooling and ops utilities around the jvm

The language changes the underlying values

only to make them worse, as far as ops is concerned

And yet, declarative descriptions of infrastructure rule the space.

I need to rest, but thanks for the conversation

Cheers

cheers