🐛 Docker version fails to build #242
Comments
|
To reduce notifications, issues are locked until they are 🏁 status: ready for dev and to be assigned. You can learn more in our contributing guide https://github.com/neon-mmd/websurfx/blob/rolling/CONTRIBUTING.md |
neon-mmd
added
💻 aspect: code
🟥 priority: critical
🛠 goal: fix
🏁 status: ready for dev
🔢 points: 5
and removed
🚦 status: awaiting triage
labels
|
The issue has been unlocked and is now ready for dev. If you would like to work on this issue, you can comment to have it assigned to you. You can learn more in our contributing guide https://github.com/neon-mmd/websurfx/blob/rolling/CONTRIBUTING.md |
|
Thanks ❤️ for taking the time to open this issue. We really appreciate it 👍 as this helps us improve the project 🙂 . Ok, I think I know this issue and I would like to suggest trying the below FROM rust:latest AS chef
# We only pay the installation cost once,
# it will be cached from the second build onwards
RUN cargo install cargo-chef
WORKDIR /app
FROM chef AS planner
COPY . .
RUN cargo chef prepare --recipe-path recipe.json
FROM chef AS builder
COPY --from=planner /app/recipe.json recipe.json
# Build dependencies - this is the caching Docker layer!
RUN apt-get update -y && apt-get install sudo apt-get install -y --no-install-recommends liblua5.4-dev liblua5.3-dev liblua5.2-dev liblua5.1-0-dev libluajit-5.1-dev
RUN cargo chef cook --release --recipe-path recipe.json
# Build application
COPY . .
RUN cargo install --path .
# We do not need the Rust toolchain to run the binary!
FROM gcr.io/distroless/cc-debian12
COPY --from=builder /app/public/ /opt/websurfx/public/
COPY --from=builder /app/websurfx/config.lua /etc/xdg/websurfx/config.lua
COPY --from=builder /app/websurfx/config.lua /etc/xdg/websurfx/allowlist.txt
COPY --from=builder /app/websurfx/config.lua /etc/xdg/websurfx/blocklist.txt
COPY --from=builder /usr/local/cargo/bin/* /usr/local/bin/
CMD ["websurfx"] |
|
Changes applied as suggested to the Dockerfile, New Error: EDIT: I changed Line 15 to remove "sudo" as it was already installed. It seems to be running now, I will update after this. |
|
It built but now won't start: |
Sorry for the delay in the reply. Ok, I would like to suggest trying the below The new DockerfileFROM rust:latest AS chef
# We only pay the installation cost once,
# it will be cached from the second build onwards
RUN cargo install cargo-chef --locked
WORKDIR /app
FROM chef AS planner
COPY . .
RUN cargo chef prepare --recipe-path recipe.json
FROM chef AS builder
COPY --from=planner /app/recipe.json recipe.json
# Build dependencies - this is the caching Docker layer!
RUN cargo chef cook --release --recipe-path recipe.json
# Build application
COPY . .
RUN cargo install --path .
# We do not need the Rust toolchain to run the binary!
FROM gcr.io/distroless/cc-debian12
COPY --from=builder /app/public/ /opt/websurfx/public/
COPY --from=builder /app/websurfx/config.lua /etc/xdg/websurfx/config.lua
COPY --from=builder /app/websurfx/allowlist.txt /etc/xdg/websurfx/allowlist.txt
COPY --from=builder /app/websurfx/blocklist.txt /etc/xdg/websurfx/blocklist.txt
COPY --from=builder /usr/local/cargo/bin/* /usr/local/bin/
CMD ["websurfx"]The new Cargo.toml file[package]
name = "websurfx"
version = "0.21.0"
edition = "2021"
description = "An open-source alternative to Searx that provides clean, ad-free, and organic results with incredible speed while keeping privacy and security in mind."
repository = "https://github.com/neon-mmd/websurfx"
license = "AGPL-3.0"
[dependencies]
reqwest = {version="0.11.20",features=["json"]}
tokio = {version="1.32.0",features=["rt-multi-thread","macros"]}
serde = {version="1.0.188",features=["derive"]}
handlebars = { version = "4.4.0", features = ["dir_source"] }
scraper = {version="0.17.1"}
actix-web = {version="4.4.0", features = ["cookies"]}
actix-files = {version="0.6.2"}
actix-cors = {version="0.6.4"}
serde_json = {version="1.0.105"}
fake-useragent = {version="0.1.3"}
env_logger = {version="0.10.0"}
log = {version="0.4.20"}
mlua = {version="0.8.10", features=["luajit", "vendored"]}
redis = {version="0.23.3", features=["tokio-comp","connection-manager"], optional = true}
md5 = {version="0.7.0"}
rand={version="0.8.5"}
once_cell = {version="1.18.0"}
error-stack = {version="0.4.0"}
async-trait = {version="0.1.73"}
regex = {version="1.9.4", features=["perf"]}
smallvec = {version="1.11.0", features=["union", "serde"]}
futures = {version="0.3.28"}
dhat = {version="0.3.2", optional = true}
mimalloc = { version = "0.1.38", default-features = false }
async-once-cell = {version="0.5.3"}
actix-governor = {version="0.4.1"}
mini-moka = { version="0.10", optional = true}
[dev-dependencies]
rusty-hook = "^0.11.2"
criterion = "0.5.1"
tempfile = "3.8.0"
[profile.dev]
opt-level = 0
debug = true
split-debuginfo = '...'
debug-assertions = true
overflow-checks = true
lto = false
panic = 'unwind'
incremental = true
codegen-units = 256
rpath = false
[profile.release]
opt-level = 3
debug = false # This should only be commented when testing with dhat profiler
# debug = 1 # This should only be uncommented when testing with dhat profiler
split-debuginfo = '...'
debug-assertions = false
overflow-checks = false
lto = true
panic = 'abort'
incremental = false
codegen-units = 1
rpath = false
strip = "debuginfo"
[features]
default = ["memory-cache"]
dhat-heap = ["dep:dhat"]
memory-cache = ["dep:mini-moka"]
redis-cache = ["dep:redis"]
hybrid-cache = ["memory-cache", "redis-cache"]
|
|
Progress? |
Yes, the previous error is fixed. So we have some progress here 🙂 . I think I know the issue again this time and as such I would suggest updating your config file to look something like this (based on the docs): -- ### General ###
logging = true -- an option to enable or disable logs.
debug = false -- an option to enable or disable debug mode.
threads = 10 -- the amount of threads that the app will use to run (the value should be greater than 0).
-- ### Server ###
port = "8181" -- port on which server should be launched
binding_ip = "0.0.0.0" --ip address on the which server should be launched.
production_use = false -- whether to use production mode or not (in other words this option should be used if it is to be used to host it on the server to provide a service to a large number of users (more than one))
-- if production_use is set to true
-- There will be a random delay before sending the request to the search engines, this is to prevent DDoSing the upstream search engines from a large number of simultaneous requests.
request_timeout = 30 -- timeout for the search requests sent to the upstream search engines to be fetched (value in seconds).
rate_limiter = {
number_of_requests = 20, -- The number of request that are allowed within a provided time limit.
time_limit = 1, -- The time limit in which the quantity of requests that should be accepted.
}
-- ### Search ###
-- Filter results based on different levels. The levels provided are:
-- {{
-- 0 - None
-- 1 - Low
-- 2 - Moderate
-- 3 - High
-- 4 - Aggressive
-- }}
safe_search = 2
-- ### Website ###
-- The different colorschemes provided are:
-- {{
-- catppuccin-mocha
-- dark-chocolate
-- dracula
-- gruvbox-dark
-- monokai
-- nord
-- oceanic-next
-- one-dark
-- solarized-dark
-- solarized-light
-- tokyo-night
-- tomorrow-night
-- }}
colorscheme = "catppuccin-mocha" -- the colorscheme name which should be used for the website theme
theme = "simple" -- the theme name which should be used for the website
-- ### Caching ###
redis_url = "redis://redis:6379" -- redis connection url address on which the client should connect on.
-- ### Search Engines ###
upstream_search_engines = {
DuckDuckGo = true,
Searx = false,
} -- select the upstream search engines from which the results should be fetched.Again, let us know if this fixes your issue 🙂 . |
|
No fix. I tried your version you posted above, as well as double checked mine beforehand - page will not load. Mine was set to 127.0.0.1., I changed it to 0.0.0.0 on my first attempt, otherwise it was already set to answer on 8181. I ran the docker compose -d --build and it says it's running but no page availability. So, I deleted my config.lua and rebuilt it again with your version and same problem using the same docker compose method. I had to chuckle at this one, while in Dozzle, looking for any log information (there's none), I think you have achieved the ultra low load record on my system!!!! |
Ok, is it the same when you access it through Also, I would suggest you to run this on the command line. Let us know what does this show when you run it: docker compose logs -f |
|
This isn't on a local server as in on 127.0.0.1 - it's on a different computer so using 127.0.0.1:8181 will point to my computer which wouldn't be running it. from the
|
|
Got it working, changed the network to "Host" and can see the page now. Search speed is slow though - but may be due to machine. CPU: quad core Intel Core i5-2400 (-MCP-) speed/min/max: 3294/1600/3400 MHz Anyway, probably can close this now. :) |
Yes, maybe because on my system it runs really fast. But anyway, nice to hear that the issue got resolved 🙂 . Thanks ❤️ again for opening this issue. Now Since everything looks good. I will close this issue right away 🚀 🙂 . |
Description
This errors out when building the Docker version. The before line through to the stop point:
Screenshots
No response
Do you want to work on this issue?
None
Additional information
No response
The text was updated successfully, but these errors were encountered: