Running behind proxy?

[ieugen]

Hello,

How can I run the application behind an http proxy like apache or nginx?
My setup uses apache to handle SSL and so far Alf seems to ignore all the normal HTTP headers like x-forwarded-for or x-forwarded-proto for working in such a scenario.

Thank you,

[cbellone]

Hi @ieugen,

Alf.io supports the X-Forwarded-proto for ssl termination. This header is frequently used by PaaS providers (see website for the guides).

We would strongly suggest to use docker, as documented in the readme.

I'm closing this because it's not really an issue. Next time please write to the mailing list.

Celestino

[ieugen]

Hi,

Thank you clearing things. I managed to deploy it [1] but I did some changes to the code and build system [2].

I know people use docker but that doesn't mean I have to do too. I don't like docker. It adds another layer that I don't need so please don't force me (the user) to use it.

I deploy using systemd service and I've changed the build to produce a binary distribution that does start the embedded tomcat.

I have production experience and would like to contribute some stuff. Some of them are in the branch but not quite ready for merging.

[1] https://bileterie.ro/
[2] https://github.com/netdava/alf.io/tree/production-fix
[3] https://gist.github.com/ieugen/9106c9cbd37453f9ed61

[cbellone]

Hi @ieugen,

Docker is not (only) about buzzwords, it is a good and effective way to encapsulate services. For instance, using our docker image people simply can't access the 8080 port directly, because that port is not bound on the public ip.

Thank you clearing things. I managed to deploy it [1] but I did some changes to the code and build system [2].

I actually managed to access your running system [1] using HTTP (I can share details via private e-mail if needed), so I am still convinced that removing the RedirectToHttpsFilter, which is an important piece of the security infrastructure, is not a good idea.
Please subscribe to the mailing list (https://groups.google.com/d/forum/alfio): some people there (like @mg-1999 ) managed to run alf.io without using docker on Digital Ocean.

I deploy using systemd service and I've changed the build to produce a binary distribution that does start the embedded tomcat.

we'll support that in the next releases (1.8 or 1.9), when we'll update spring-boot version to 1.3 (see https://github.com/spring-projects/spring-boot/wiki/spring-boot-1.3-release-notes#fully-executable-jars-and-service-support). Thanks for pointing it out.

I have production experience and would like to contribute some stuff

That's great, every contribution is welcome! @mg-1999 is working on a step-by-step guide "how to deploy alf.io on Digital Ocean", maybe you could add a "let's encrypt" section there. That would be really appreciated. Thank you!

[ieugen]

Hi,

I'm not denying docker is useful or good. I just don't want to use it when I don't have to. It's another layer.

I think it's best practice for the app to bind to localhost and provide an easy way to change that (I think server.address will work). Right now the application.properties is packaged with the jar and changing it is difficult [1]. I think it is possible to provide a system property for that, but should be documented.

@mg-1999: let me know how I can contribute.

[`1] http://12factor.net/

[cbellone]

#52

Search is your friend.

As already said, pull requests for the documentation are welcome.
On 12 Mar 2016 2:10 pm, "Ioan Eugen Stan" notifications@github.com wrote:

Hi,

I'm not denying docker is useful or good. I just don't want to use it when
I don't have to. It's another layer.

I think it's best practice for the app to bind to localhost and provide an
easy way to change that (I think server.address will work). Right now the
application.properties is packaged with the jar and changing it is
difficult [1]. I think it is possible to provide a system property for
that, but should be documented.

@mg-1999 https://github.com/mg-1999: let me know how I can contribute.

[`1] http://12factor.net/

—
Reply to this email directly or view it on GitHub
#105 (comment).

[ieugen]

Thanks. It's much better to keep the configuration and all the data the application produces outside the application directory. This way you can upgrade very easily. You just unpack the latest version and point it to the configuration and data directory and start the new app.

My usual setup (sysadmin approved) is like this:

/opt/alfio/conf -> configuration folder
/opt/alfio/logs -> log files
/opt/alfio/releases -> keep all version of alfio you deploy (or just the latest 2-5)
/opt/alfio/current -> symbolic link to the latest deployed version 
/opt/alfio/data -> keep all the application produced data not in DB

Having this setup, upgrading is easy and rolling back is possible.

Upgrade:

• unpack new version in releases
• update symbolic link to new version
• restart the service

The only downtime you have depends on how fast your application starts.
Rolling back (if you don't have tricky migrations) is done by pointing current to the release-1 and restarting the service.

Backing up is easy: just copy conf and data and maybe logs.

[mg-1999]

I just run Alf.io in a screen session and use NGINX as a proxy and set the ssl certificate with it. I also block port 8080 with ufw and open port 443.

[ieugen]

@mg-1999 if you bind to localhost there is no need for firewalling any port since the app is not available from public internet except through proxy.