Cleanup/Improve Platform.sh config for 1.13 (and up) #234
Conversation
.platform.app.yaml
Outdated
| @@ -64,7 +72,9 @@ hooks: | |||
| php -d memory_limit=-1 app/console ezplatform:install --env=$SYMFONY_ENV $INSTALL_EZ_INSTALL_TYPE | |||
| touch web/var/.platform.installed | |||
| fi | |||
| app/console --env=$SYMFONY_ENV cache:clear | |||
There was a problem hiding this comment.
Why would you remove this? on code changes (DI related for instance ) you need to clear the cache too if you wanna be safe....
There was a problem hiding this comment.
Isn't deploy effectively a new node with empty cache? (locally)
My assumption was that, and that the cache clear was needed since we shared it on NFS.
There was a problem hiding this comment.
Nope, it is the same node every time. So you do for instance reuse the same composer cache during build....
But if you don't declare it as a share, it should in practice be empty on deployment. But it will also be read-only.... If application want to write something, it must be to a shared mount...
AFAIK, with symfony 3.x, the cache might be committed to git as it has no DB info etc, right ?
but for 2.x, this must be a volume.
But also note that shared mounts are not NFS..... it is a shared block device something. I don't know the technical details. I have not performance tested it, but I assume it outperforms NFS
update: The new cache stuff mentioned seems to be a symfony 4.x feature, not a 3.x feature
.platform.app.yaml
Outdated
| @@ -36,7 +45,6 @@ disk: 2048 | |||
|
|
|||
| # The mounts that will be performed when the package is deployed. | |||
| mounts: | |||
| "/app/cache": "shared:files/cache" | |||
There was a problem hiding this comment.
We cannot remove this line I think.
Well, maybe for professional subscription cause that is atm a single host environment ( I believe platform.sh might introduce multi nodes in the biggest subscription plans shortly though)
On enterprise there will be no convenient way of clearing the cache unless this is shared among the nodes
There was a problem hiding this comment.
But this is an major anti pattern:
- Its code cache so should follow the code and not be shared and risk being wrong during deploy of new nodes
- It's cache, placing it on shared mount makes the benefit of having a cache go away
- sharing it means you have to clear it, and it will take much longer to clear it, and you can end up in race conditions when several nodes are deployed at once
For eZ Publish 5.x and eZ Platform we clearly state app/cache is not meant to be shared among severs for cluster use.
--
But there is an blocker here that I forgot about when opening this: The reason why this line is here is because Symfony needs to write to cache folder. And if this is removed it will not be writeable after build stage
This seems to have been fixed in Symfony 4, but does not seems to have been fixed in earlier versions. (well, maybe, but both doc and the platform.sh config seems to indicate writable cache folder is a must)
.platform.app.yaml
Outdated
| @@ -64,7 +72,9 @@ hooks: | |||
| php -d memory_limit=-1 app/console ezplatform:install --env=$SYMFONY_ENV $INSTALL_EZ_INSTALL_TYPE | |||
There was a problem hiding this comment.
Side: This previously attempted to write to disk, it now clear caches by using cache pool, see: ezsystems/ezpublish-kernel#2180
|
@vidarl you're right, app/cache needs to be writable, it's not safe to assume something else for now. as lots of bundles assumes they can write to cache folder. Only Symfony 4 changes this. So instead made changes here to minimize amount of stuff is placed in the shared app/cache, minimizing the issue. In parallel will be looking with p.sh towards allowing local writable mount for use for caching so it's not shared but rather per host. Also added session storage in redis here, but that might be something @glye already tested back during the spring and found issues with. |
I don't think so. It's so long ago that it would need new testing now, anyway. |
app/config/env/platformsh.php
Outdated
| @@ -47,5 +51,7 @@ | |||
| // Disable PHPStormPass | |||
| $container->setParameter('ezdesign.phpstorm.enabled', false); | |||
|
|
|||
| // Store session into /tmp. | |||
| ini_set('session.save_path', '/tmp/sessions'); | |||
| // Load platform.sh specifc settings | |||
app/config/env/platformsh.yml
Outdated
| @@ -0,0 +1,16 @@ | |||
| # To make sure as littel as possible cache is written to the shared mount we use apc and redis (for cache that needs to be shared) | |||
There was a problem hiding this comment.
"as little cache as possible"
|
@SylvainGuittard Looks ok? And I assume when platformsh job here says it's green the config works right? |
|
@andrerom If it's green it's a good sign regarding the deploy script. And it is. Here is the output: When you click on the link, the server returns an internal server error 500. So, it seems that Redis is not happy and I don't understand why |
|
We are running netmaking.no on Platform.sh and are in need of search (for instance Solr). If needed, I'd be happy to do som testing when and if needed. |
.platform.app.yaml
Outdated
| php: | ||
| "display_errors": "Off" | ||
| session.save_handler: redis | ||
| session.save_path: "tcp://sessionstorage.internal:6379" |
There was a problem hiding this comment.
todo, this needs to be kept in app/config/env/platformsh.php so it can be properly extracted from the relationships data which sometimes will differ from deploy to deploy.
1a3d975 to
5c0955f
Compare
.platform/services.yaml
Outdated
| # core1: | ||
| # conf_dir: !archive "solr/config/solr" | ||
| # endpoints: | ||
| # endpoint0: |
There was a problem hiding this comment.
Is endpoint0 a significant name in eZ? If not, something like "main" seems like it would be more user-friendly.
There was a problem hiding this comment.
it's also used in default config: https://github.com/ezsystems/ezplatform/blob/master/app/config/config.yml#L36
But there might still be some miss alignment here.
There was a problem hiding this comment.
If it works it works; I just prefer less machine-y names in a user-visible file most of the time is all.
.platform.app.yaml
Outdated
| @@ -40,46 +52,52 @@ disk: 2048 | |||
|
|
|||
| # The mounts that will be performed when the package is deployed. | |||
| mounts: | |||
| # NOTE: Once possible, cache folder will rather be configured as local writable mount | |||
There was a problem hiding this comment.
This comment is PE-specific, and this configuration applies to PS. It can be removed.
There was a problem hiding this comment.
didn't you or someone mention there will be a new mount format for PS (gen2) which also allows to specify a mount as local, which hopefully eventually will be supported by PE (wings) as well so the fomat can stay the same between the two?
There was a problem hiding this comment.
There is a new mount format for PS only that's already been deployed. With Wings, PE can be set to pull its mount information from the .platform.app.yaml file iff:
- They're in the old-style format
- No mounts on PE need to be
local, they can all be shared by all webheads.
Since point 2 is not true for eZ, we cannot rely on that and the mount section here will be for PS only and will be ignored on PE. I'm working on internal documentation for us on how to setup the PE mounts for eZ by default. There's no need to reference that here.
There was a problem hiding this comment.
We can remove the comment for now, but we need to have one config that works on both and works good (shows best practice). Currently that is impossible since Wings does not support new things coming in PS, is there a chance this is solved by fall?
.platform.app.yaml
Outdated
| app/console cache:clear | ||
| # If this is not a "fast-deploy" then typically you would want to migrate your data as well here | ||
| #app/console doctrine:migrations:migrate --no-interaction --allow-no-migration | ||
| #app/console kaliop:migration:migrate --no-interaction --no-debug |
There was a problem hiding this comment.
Remember, this is on PS... I don't know what you mean by "fast-deploy" here. (It was an older feature on PE that isn't really a thing on Wings now, IIRC.)
Something to consider: Move the entire deploy hook to a deploy.sh file, which we can then reference from the PE setup as well. That way users can still customize their deploy hook without having to notify the Platform.sh support team. The commented out lines here suggest that you intend for users to be editing these possibly often, in which case that would help eliminate a step.
There was a problem hiding this comment.
Move the entire deploy hook to a deploy.sh file,
good suggestion.
Same for build?
I don't know what you mean by "fast-deploy" here
from what I been told there is a PS (gen2) option for this involving putting incomming requests on hold during deploy time.
There was a problem hiding this comment.
The build hook is controlled from the .platform.app.yaml file regardless of PS or PE, so there's no need to split it off. You could if you want to but there's no compelling reason to.
We already put incoming requests on hold during deploy on PS. On PE the VMs just go offline entirely for a moment, but with a CDN in front of them 99.9% of users won't notice. There was a flag on PE called fast-deploy that I think skipped the deploy hook, or reopened the site before the deploy hook finished, or something, but it doesn't apply anymore in Wings so you can/should ignore its existence.
Just assume that the deploy hook will always run, the same, and block the site coming back up regardless of whether you're on PS or PE, so keep it short.
.platform/routes.yaml
Outdated
| @@ -4,6 +4,7 @@ | |||
| cache: | |||
| # As this does not support Vary, and purging, we can't use this as Sf Proxy drop in. | |||
| # However it is possible to enable this for anonymous traffic when backend sends expiry headers. | |||
| # Note: Recommended option for Enterprise use is to use ezplatform-http-cache-fastly bundle | |||
There was a problem hiding this comment.
Grammar suggestion: "eZ Platform Enterprise users are encouraged to use Fastly and enable the ezplatform-http-cache-fastly bundle."
There was a problem hiding this comment.
I actually picked that wording specifically not to make distinction between eZ Platform Enterprise and Platform.sh Enterprise here, given you'll need both in order to be able to take advantage of it.
And once you can, it's strongly recommended, and not just encouraged. As we only support usage of Varnish/Fastly as a shared proxy on cluster installs, we don't support the file based Symfony proxy in this scenario, which would involve sharing cache over nfs, and neither does Symfony (they recommend Varnish, and discourages use of nfs for cache, including HttpCache).
Now that you know most of the context, suggestions welcome :)
There was a problem hiding this comment.
Well, the current text isn't a valid grammatical sentence in English so we should tweak it regardless. 😄
We strongly recommend that users of eZ Platform Enterprise on Platform.sh Enterprise use the ezplatform-http-cache-fastly bundle and set this value to false.
See: *link to the docs for how to set that up*
Since eZ Platform on PS and eZ Platform Community on PE are both still legit things for people to do, even if we want them to go double-Enterprise.
| @@ -1,5 +1,5 @@ | |||
| mysqldb: | |||
| type: mysql:10.0 | |||
| type: mysql:10.1 | |||
There was a problem hiding this comment.
You can go all the way to 10.2 if you want. 😄
There was a problem hiding this comment.
We have reports on some issues with 10.2 for those still using eZ Publish legacy with this, so this was on purpose not bumped up to that yet. Also we have no tests running on it yet, automated or manual.
app/config/config_prod.yml
Outdated
| @@ -2,15 +2,25 @@ imports: | |||
| - { resource: config.yml } | |||
| - { resource: ezplatform_prod.yml } | |||
|
|
|||
| # If you are on platform.sh/docker or similar where app/cache is not writable during runtime | |||
There was a problem hiding this comment.
Please capitalize Platform.sh
6b4ad10 to
5edcb3a
Compare
app/config/env/platformsh.yml
Outdated
| # To make sure as little cache as possible is written to the shared mount we use apc and redis (for cache that needs to be shared) | ||
|
|
||
| imports: | ||
| - { resource: ../cache_pool/singleredis.yml } |
There was a problem hiding this comment.
We can skip this one now I guess, as it's loaded in platformsh.php, cc @vidarl
…avoid implying it will work out of the box
Suggestions for improving the default config to be more cluster aware, and try to reduce how much cache we put on shared disk as it is shared (for now, plan is to move it to local disk once p.sh config allows us to later).
Todo: