News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

SMF 2.1 (containerized setup)

Started by danielrichter, April 30, 2022, 06:52:35 AM

Previous topic - Next topic

danielrichter

Dear SMF community,

working on setup of SMF in a containerized environment (kubernetes).
I would like to use this thread to gather all important things to take care of for such a setup:

  • make sure Upload directory (default) /forum/custom_avataris mounted as sharedVolume between all pods
  • make sure Avatars directory (default) /forum/avatarsis mounted as sharedVolume between all pods
  • make sure Attachments directory (default) /forum/attachmentsis mounted as sharedVolume between all pods
  • make sure Caching is set to Memcached | Memcache (my redis cache driver is currently under SMF review)
  • make sure Use database driven sessions is set to true / on (otherwise the user might occur "being logged out" when the request hit another pod)

Are there any plans for SMF to support session drivers too? So session data can be written to memcached / redis?

The list will be updated to make sure this main post contains all informations.
Let me know any other things which need to be considered when SMF is running in a containerized environment.

Arantor

As I told you before if you turn off DB sessions and tell PHP itself to point at Redis (or memcache) in PHP's ini file it'll work just fine that way.

/forum/avatars is only relevant if you add new avatars to the gallery; user avatars are not stored here.

You might also consider adding the Smileys folder as a shared folder if anyone adds new smileys so they get shared everywhere.

I also presume you have no plans to ever use the package manager for SMF security patches or addons because this will not work in your environment.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

danielrichter

Quote from: Arantor on April 30, 2022, 10:58:25 AMAs I told you before if you turn off DB sessions and tell PHP itself to point at Redis (or memcache) in PHP's ini file it'll work just fine that way.

Already tried this, edit php.ini, make sure to comment out / enter this lines:

session.save_handler = redis
;session.save_handler = files
session.save_path = "tcp://127.0.0.1:6379"
;session.save_path = "/var/lib/php/sessions"

Restart webserver and check sessions inside redis:

Quoteroot@workstation:~# redis-cli
127.0.0.1:6379> keys *
1) "PHPREDIS_SESSION:5cg7effra7ftku3nalv4oh5lcg"

After this delete the whole redis cache by using:

Quote127.0.0.1:6379> flushall
OK
127.0.0.1:6379> keys *
(empty list or set)

Reload the SMF website and you can see the session is restored again (user is NOT logged out and session exists in redis again):

Quote127.0.0.1:6379> keys *
3) "PHPREDIS_SESSION:5cg7effra7ftku3nalv4oh5lcg"

Is this "normal" behavior inside SMF / can someone explain me this? Not the way I expect it to work.

Thank you for your hint regarding Smileys folder.
On each new SMF release the version of SMF inside the container needs to updated and the whole deployment will be rolled out again, it's not possible to use SMF internal updater inside this setup, yes.

Arantor

Yes, the session is not the primary holder of the user's authentication status. If it was, "forever" wouldn't ever work because sessions would be garbage collected within an hour on most setups.

What happens is that the cookie itself contains enough information to authenticate the user and then the session contains the very local things, e.g. CSRF tokens and the like.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

danielrichter

Will it make sense to share Themes folder between all pods too?

Arantor

Sort of, this one's trickier. You'll be managing core changes through your code base management but the minified CSS/JS files will be produced into the theme folders so either you need to turn that off or make it writable.

Does it need to be shared? Complicated question because the files can always be regenerated as needed.

On that note you will need to share your cache folder between the pods because there are some operations that use the cache folder (I think this is where the image proxy drops its files) and wherever data exports are configured to be should also be shared.

SMF was really really not designed for this type of setup, and I do not anticipate this being made significantly easier any time soon because the (vast) majority of users are using conventional shared hosting which must be the focus of development efforts.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

danielrichter

@Arantor
Thank you  :-*
Works good until now.

Is there any section where I can submit the idea to make SMF a bit more optimized for running in a container setup?

Arantor

You can try making a topic in Feature Requests but honestly... it's a minority use case in reality.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

Advertisement: