🎉 Need help with `v3` alpha|beta testing

tarampampam commented 1 month ago

Hello everyone!

I've been working hard over the past few weeks on a major version of this project, and my work is nearly complete. The most important parts are done and ready to be tested. Please note that the following changes are not backward-compatible, which is why this is a major update:

The configuration file (error-pages.yml) is no longer needed. Everything is now configured using CLI flags and environment variables
The app is built with templates from this repository (they are built-in to the app binary file), and you can still use custom templates using the flag --add-template /path/to/your/tpl.htm
While most CLI flags and environment variables remain the same as in v2, some have changed. Please update your charts accordingly. For the latest information, check here. The README file is still in progress, but the CLI documentation is available
The error pages can now be accessed using the following URLs - /{code}, /{code}.html, and /{code}.htm. Additionally, you can use the flag --send-same-http-code to retain the same HTTP status code as the page, if needed
To override or append a custom code, you can do this using the flag --add-http-code="…" in the format %code%=%message%/%description%. Moreover, you can use "placeholder" codes like 4**, which means if the requested code is not described but is between 400 and 499, the provided message with its description will be returned. This approach is similar to the one used in the OpenAPI specification, where instead of describing each code individually, you can describe a pattern
The default content type for error pages is now PlainText. This means that when you curl an error page, you will receive more readable content without tons of HTML tags. This change should not cause any issues, but it may
I am still deciding on two things - whether to keep the fasthttp HTTP server or switch to the stdlib HTTP server, and whether to keep the templates caching mechanism used in v2. Currently, I have switched to the stdlib HTTP server (due to better support and built-in HTTP/2 support, though with lower performance - 40k RPS has dropped to 11k). I've also removed the caching mechanism, which should reduce memory consumption but may increase CPU load slightly. I haven't finalized these decisions yet, so please share your thoughts
The templates have been redesigned to be more responsive. A dark theme is now automatically applied if the user prefers it. Themes l7-dark and l7-light have been merged into a single l7 theme, and the matrix theme has been removed (because I created it and it wasn't very appealing)
The templates no longer download anything from the far-far galaxies - everything is now embedded, including the localization script, which is now inlined into the page. Additionally, custom fonts have been removed
The metrics endpoint /metrics has been not implemented yet, If someone found it useful and has used it - just tell me, and I'll re-implement it
I'll add any other important updates here later

I'm reaching out to see if anyone would like to assist with early testing of the app. I can provide early builds (Docker image tags) via messages in this thread. It would be fantastic if you could run them locally or on your staging cluster and provide feedback on whether everything is working smoothly or if you encounter any issues.

Please leave a comment to let me know if you're willing to help. Your assistance would be greatly appreciated!

/cc @deffcolony @moschlar @r2DoesInc @fuog @kfirfer @CodeAnthem @NicosKaralis @GoliathLabs @onedr0p @modem7 @ToshY

tarampampam commented 1 month ago

And yes - the first tag is ghcr.io/tarampampam/error-pages:3.0.0-alpha-1 😆

r2DoesInc commented 1 month ago

I'll absolutely be checking it out and will provide my feedback.

I've integrated this project into the templates of all my own apps, I very much appreciate the work put in.

On Sat, Jun 29, 2024, 2:36 PM Pаramtamtām @.***> wrote:

And yes - the first tag is ghcr.io/tarampampam/error-pages:3.0.0-alpha-1 😆

— Reply to this email directly, view it on GitHub https://github.com/tarampampam/error-pages/issues/288#issuecomment-2198291507, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD63FOLFK5KZYTPZLYVEMLZJ35EBAVCNFSM6AAAAABKDMXMNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGI4TCNJQG4 . You are receiving this because you were mentioned.Message ID: @.***>

cathelijne commented 4 weeks ago

Used the alpha version on my internal ingress for a couple of days. No issues at all.

Configured an ingress to test error codes:

location /418 {
  return 418;
}

and so on, and it picked up all codes beautifully.

Text-only results for curl much appreciated!

Planning to test the drop-in templates with --add-template later, but it might be a few days before I come around to that.

Like the previous poster I love these error pages, I haven't looked back since I found them.

tarampampam commented 4 weeks ago

fasthttp is back! ghcr.io/tarampampam/error-pages:3.0.0-alpha-2

[!NOTE] RPS 11k → 18k

r2DoesInc commented 4 weeks ago

@tarampampam You mentioned in https://github.com/tarampampam/error-pages/issues/257 that this v3 update would work to resolve the issue described.

Is this something that is currently achievable or still in the works? I see the ability to override the json response, but I need to do so per request rather than at the serve level.

Ive not yet tried the update, hoping to get some time this week to start working on things again.

tarampampam commented 4 weeks ago

After getting some sleep and rerunning the performance tests, I obtained some interesting results:

Version	Description	RPS	Mem usage (under load / idle)
`2.27.0`	`fasthttp` + templates caching	102k	~25MiB / ~20MiB
`3.0.0-alpha-1`	`stdlib.http`	25k	~53MiB / ~28MiB
`3.0.0-alpha-2`	`fasthttp` + `--read-buffer-size 5120`	39k	~100MiB / ~93MiB
`3.0.0-alpha-2`	`fasthttp` + `--read-buffer-size 5242880 # 5 MiB`	45k	~2GiB
`3.0.0-alpha-3`	`fasthttps` + templates caching + `--log-level warn`	122k 🔥	~75MiB

[!NOTE] To run performance tests the following command was used: wrk --timeout 1s -t12 -c400 -d30s -s ./test/wrk/request.lua http://127.0.0.1:8080/

Increasing the read-buffer-size significantly affects memory usage. Therefore, I have reinstated the CLI flag --read-buffer-size to allow for fine-tuning, instead of the previously hardcoded buffer size used for experiments 😆

I've encountered a bit of a challenge - in order to cache templates, I need to cache everything, including the results of functions like fetching current timestamps. With a cache TTL of 1 second, it's impossible to render timestamps with milliseconds or nanoseconds in the template (and this caching approach could potentially affect other aspects). In short, I'm facing a classic programming dilemma — cache invalidation. I'm still contemplating how best to resolve it

Update: I have implemented template caching for 900 milliseconds, and as expected, it boosted the RPS by approximately 220%. Since no issues have been reported for the previous versions, I will keep it.

The tag with template caching is ghcr.io/tarampampam/error-pages:3.0.0-alpha-3.

tarampampam commented 4 weeks ago

I've released the first beta version: v3.0.0-beta-1 (ghcr.io/tarampampam/error-pages:3.0.0-beta-1).

I'll wait a few days for testing. If you confirm that everything is okay and no issues are found, I'll go ahead and release a stable version. Does that sound good?

deffcolony commented 3 weeks ago

@tarampampam Does this include the support of my issue at #285 ?

tarampampam commented 3 weeks ago

Does this include the support of my issue at #285 ?

Since there is no longer a config file - simply mount the HTML file with your template, set the --template-name to it, and that's it! This is why I closed your issue. If I've missed something, please let me know.

[!NOTE] I have updated the readme file: https://github.com/tarampampam/error-pages/blob/b4e9ea5ea65109aba3a0aa2942a1d4ceef294f1a/README.md?plain=1#L111-L153

ToshY commented 3 weeks ago

Hey @tarampampam 👋

I have some questions looking through the (new) README. I have compose configs which still contain DEFAULT_HTTP_CODE (introduced in v2.3.0) and CATCH_ALL (introduced in v2.5.0) environment variables. I don't see a mention that they have been deprecated, removed or replaced by something else. Will they still be used in v3 or will they be replaced/removed entirely?

If that's clear to me, I can adjust my configs and start trying out the new v3 beta image too 👌

p.s.

Thank you for your continued hard work 🥇

tarampampam commented 3 weeks ago

@ToshY I'm currently collecting all the changes in the first comment in #287, which will become the release description. This is why I haven't yet written an upgrade guide in the README file. Yes, those environment variables have been removed and are no longer needed. If you could share your experience upgrading from v2 to v3, I would greatly appreciate it, as it may help others have a smoother upgrade process!

p.s. TY for your help with testing!

deffcolony commented 3 weeks ago

Since there is no longer a config file - simply mount the HTML file with your template, set the --template-name to it, and that's it! This is why I closed your issue. If I've missed something, please let me know.

so i was looking at the docker-compose.yml file at https://github.com/tarampampam/error-pages/blob/master/compose.yml

i am used to always mount the files that are inside the container into the host so users can manually edit. Does this mean i can set my docker-compose.yml like this? is this the correct way to mount the files from the src folder? and do i really need 2 containers for web and develop? all i want is just the mount point so i can import my own 403 forbidden page for example

services:
  error-pages:
    image: ghcr.io/tarampampam/error-pages:latest 
    container_name: error-pages
    volumes:
      - ./error-pages/data:/src
    ports:
      - "8176:8080"
    restart: unless-stopped

My goal is that i want to provide a custom error page folder with custom assets ill explain this in more detail below:

I'm currently setting up a custom error page solution for my selfhosted services using Traefik and Nginx, but I'm running into an issue where the static assets for my error pages (like CSS, JS, and images) are being blocked when a 403 status is triggered. but it does not block the index.html strangely

Here's a brief overview of my setup:

Traefik: Used as a reverse proxy to handle routing and middleware.

Nginx: (i want to use error-pages for this but not sure how this will be executed with the new version) so this will hosts the custom error pages and their static assets that is being served from a subdomain (error.domain.com). When i trigger the 403 forbidden with the following config:

fileConfig.yml

http:
  routers:
    error-pages-router:
      entryPoints:
        - https
      rule: "Host(`error.domain.com`)"
      priority: 1
      service: error-pages-service
      middlewares:
        - error-pages

    # myapp router
    myapp:
      entryPoints:
        - https
      rule: "Host(`myapp.domain.com`) || Host(`myapp.local.domain.com`)"
      service: myapp
      middlewares:
        - "error-pages"
        - "ip-allowlist"

  services:
    error-pages-service:
      loadBalancer:
        servers:
          - url: "http://192.168.1.95:8175"

    # myapp service
    myapp:
      loadBalancer:
        servers:
          - url: 

  middlewares:
    error-pages:
      errors:
        status:
          - "400-599"
        service: error-pages-service
        query: "/{status}/"

    # Only Allow Local networks
    ip-allowlist:
      ipAllowList:
        sourceRange:
          -  # localhosthttp://192.168.1.95:8110127.0.0.1/32

what i see when i visit myapp where i blocked myself to trigger custom 403 error page the custom error page is displayed almost correctly since it does load index.html, but the static assets (CSS, JS, images) fail to load, resulting in 403 errors for those assets.

Browser network tab log

GET
 403 Forbidden

GET
 403 Forbidden

GET
 403 Forbidden

GET

[HTTP/3 403 Forbidden 45ms]

GET

[HTTP/3 403 Forbidden 52ms]

GET

[HTTP/3 403 Forbidden 63ms]https://myapp.domain.com/css/index.csshttps://myapp.domain.com/js/libs/log.jshttps://myapp.domain.com/js/libs/jquery.jshttps://myapp.domain.com/assets/images/doggo-sad.pnghttps://myapp.domain.com/assets/images/doggo-happy.pnghttps://myapp.domain.com/assets/images/doggo-angry.png

the file structure. again it loads the index.html but it weirdly blocks the assets, css and js folder

here is the docker-compose.yml for the custom error page.. but again i want to replicate this for the new version of error-pages

docker-compose.yml nginx

services:
  nginx-error-pages:
    image: nginx:latest
    container_name: nginx-error-pages
    volumes:
      - ./error-pages/errors:/usr/share/nginx/error-pages
      - ./error-pages/errors/config/default.conf:/etc/nginx/conf.d/default.conf
    ports:
      - "8175:80"
    restart: unless-stopped
    depends_on:
      - traefik

here is my default.conf from nginx

default.conf nginx

server {
    listen 80;
    server_name ;

    root /usr/share/nginx/error-pages;

    # Define the custom error pages
    error_page 400 /400/;
    error_page 401 /401/;
    error_page 403 /403/;
    error_page 404 /404/;
    error_page 405 /405/;
    error_page 407 /407/;
    error_page 408 /408/;
    error_page 409 /409/;
    error_page 410 /410/;
    error_page 411 /411/;
    error_page 412 /412/;
    error_page 413 /413/;
    error_page 416 /416/;
    error_page 418 /418/;
    error_page 429 /429/;
    error_page 500 /500/;
    error_page 502 /502/;
    error_page 503 /503/;
    error_page 504 /504/;
    error_page 505 /505/;

    location / {
        alias /usr/share/nginx/error-pages/200/;
    }

    # Location directives for each error page
    location /400/ {
        alias /usr/share/nginx/error-pages/400/;
    }
    location /401/ {
        alias /usr/share/nginx/error-pages/401/;
    }
    location /403/ {
        alias /usr/share/nginx/error-pages/403/;
    }
    location /404/ {
        alias /usr/share/nginx/error-pages/404/;
    }
    location /405/ {
        alias /usr/share/nginx/error-pages/405/;
    }
    location /407/ {
        alias /usr/share/nginx/error-pages/407/;
    }
    location /408/ {
        alias /usr/share/nginx/error-pages/408/;
    }
    location /409/ {
        alias /usr/share/nginx/error-pages/409/;
    }
    location /410/ {
        alias /usr/share/nginx/error-pages/410/;
    }
    location /411/ {
        alias /usr/share/nginx/error-pages/411/;
    }
    location /412/ {
        alias /usr/share/nginx/error-pages/412/;
    }
    location /413/ {
        alias /usr/share/nginx/error-pages/413/;
    }
    location /416/ {
        alias /usr/share/nginx/error-pages/416/;
    }
    location /418/ {
        alias /usr/share/nginx/error-pages/418/;
    }
    location /429/ {
        alias /usr/share/nginx/error-pages/429/;
    }
    location /500/ {
        alias /usr/share/nginx/error-pages/500/;
    }
    location /502/ {
        alias /usr/share/nginx/error-pages/502/;
    }
    location /503/ {
        alias /usr/share/nginx/error-pages/503/;
    }
    location /504/ {
        alias /usr/share/nginx/error-pages/504/;
    }
    location /505/ {
        alias /usr/share/nginx/error-pages/505/;
    }
}error.domain.com

@tarampampam How can I configure my Traefik and replicate this into the new V3 error-pages docker container setup so that the static assets for the error pages are served correctly without being 403 forbidden? Any insights or suggestions would be greatly appreciated.

tarampampam / error-pages