Documentation is here:
Yes, the pre-neo4j.sh file rewrites neo4j.conf every time -- this is necessary because certain things need to get dynamically re-written for the environment; in particular folks who use dynamic IP addresses may get a different one every time they start the VM, meaning that the VM has to detect this from the environment. Your IP address is an important part of your neo4j config (for example via default_advertised_address) so if the conf file didn't change every time neo4j restarted, then you could reboot your machine and end up with a non-working neo4j instance.
Fortunately, by editing the neo4j.template file, you still retain full control, and get some extra cloud management capabilities too (like the ability to set neo4j conf through VM tags in AWS)
Hi @david.allen I'm running 4.1 enterprise using the latest EC2 AMI (ami-0afe90add2767a91c).
I'm trying to set the tags in the EC2 instance to get them to modify the variables in neo4j.template as explained at https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html. For instance, I've created a tag with key
dbms_default_listen_address and set it to "0.0.0.0". If I understand correctly, that should modify the result of this line in the template:
But it does not change the configuration. If I could ask, what am I doing wrong?
Oh sorry -- for setting up the image as a cluster -- I simply wouldn't do that. In AWS marketplace it's already been done for you right here:
This cluster configuration is based on that same AMI you're seeing. So if you step through the flow to deploy this, you'll get a configurable "just works" type of setup out of the box. Once you've finished the deploy, you'll still own all of the VMs and be able to make whatever changes you like.
That was the image I used.
I tried it as a cloud formation template and that went fine (except one read server didn't join the cluster)
But when I tried it as an AMI, it setup as a single instance. I was going to spawn a couple of those and change their neo4j.conf files appropriately, but I'm not sure I want to mess with that shell script. The script says it uses tags to set up the conf. I would like to see some documentation on that.
My big deal with slapping my own instance of Neo4j together is that I want to know I can quickly add a core/reader as needed. I can't depend on cloud formation for all the ops tasks I'm trying to automate.
Right now I'm doing the devOps piece of my deployment strategy and I don't know how to proceed if I can't form a simple cluster.
Fair enough - you can absolutely put together the cluster yourself. You're right that the cloudformation templates are intended to deploy a cluster easily, but if you have very bespoke needs you do need to set it up to suit those needs as the template can't cover all cases.
You don't need to change pre-neo4j.sh at all, and I wouldn't recommend it. Just adjust /etc/neo4j/neo4j.template to suit your needs. What pre-neo4j.sh does it env variable substitution from environment variables (and cloud vm tags) into that file. So if you remove the variable references, you'll basically be disabling any real dynamic change that pre-neo4j.sh would do anyway.
This pre-neo4j.sh will still be in operation -- in practice though the only difference it makes to you is that you'll edit neo4j.template instead of neo4j.conf -- everything else should stay the same.