one-click-apps
one-click-apps copied to clipboard
update: strapi docker image
Update Strapi docker image since the official isn't maintained anymore.
The new image repositories are https://hub.docker.com/r/naskio/strapi
First of all, thank you for your contribution! 😄
☑️ Self Check before Merge
- [x] I have tested the template using the method described in README.md thoroughly
- [x] I have ensured that I put as much default values as possible (except passwords) to ensure minimum effort required for end users to get started.
- [x] I have ensured that I am not using the "latest" tag as this tag is dynamically changing and might break the one-click app. Use a fixed version.
- [x] I have made sure that instructions.start and instructions.end are clear and self-explanatory.
- [x] Icon is added as a png file to the logos directory.
Thanks! Can you please update the isOfficial
value?
Thanks! Can you please update the
isOfficial
value?
done!
Note: I just filed issue #787 with the following:
Strapi was recently updated with commit
bd28102
to replace the original deprecated Docker image with the newer v4-compatible imagenaskio/strapi:4.3.2
.When deployed using default settings the container fails because MongoDB is being used for the default database, but the new Strapi image requires one of
sqlite
orpostgres
ormysql
.I have modified the app template to use Strapi v4 and MySQL, and will submit that version as soon as I finish testing. The broken database may not be the only issue with
naskio/strapi
that needs to be sorted out, so I have also added a comment to the last Strapi PR #697 to discuss this further.
Problems Identified:
- [x] MongoDB is not supported
Docs
- [ ] Hostname post-deployment is
localhost
causing admin page to fail to load
At this point, I have found at least two problems with the latest Strapi image, the MongoDB issue as well as an older problem that I believe carries over from Strapi v3--immediately following deployment, the app is configured to use localhost:1337
which causes browser security policies to block the admin page from loading. This is an increasingly common type of issue that is the result of applications utilizing .env
or configuration files to define parameters that frequently aren't available as typical environment variables that can be utilized within the template itself.
Solution(s):
I have a modified 'naskio/strapi:4.3.2' OCA template using MySQL almost ready to merge which will provide an easy path to also update Strapi PostgreSQL ( #306 ). The databases work, and I have a functional but inelegant workaround for the localhost
issue that I am working on refining, ideally the template(s) can be deployed with nothing but defaults both successfully and automatically.
Before submitting these two updated templates, I wanted to get some feedback from @andrekutianski as the author of the most recent commit, and @ak4zh who merged a fix a while back ( #120 ) to the previous localhost
issue. Pinging @githubsaturn just as FYI.
Please let me know if you have been working on this, and if so I can send you my template source so we can compare notes.
My next step will be looking at #120 for possibilities to solve the localhost
problem.
Resources
- Strapi v4 @ Dockerhub
- Strapi Docs - Docker Deployments
- Strapi Docs - Database Configurations
- Strapi Docs - Nginx Proxies
- Strapi Repo - docker-compose.dev.yml
-
Strapi Dockerize is recommended under the deprecation notice at
https://github.com/strapi/strapi-docker
~~My next step will be looking at #120 for possibilities to solve the localhost
problem.~~
I tried to use the solution from #120 to fix the issue with it using localhost
, which can be seen here.
It simply uses $$cap_appname.$$cap_root_domain
as the HOST
environment variable, however that caused the errors below.
Using $$cap_appname.$$cap_root_domain
results in Strapi attempting to resolve the hostname, which on a public server such as mine results in Strapi using its public IP, but appends the http port 1337
, which of course doesn't work as my host server rejects the connection at the firewall (and wouldn't have port 1337
open outside of the container).
'2022-11-14T18:54:51.929366923Z' Admin UI built successfully
'2022-11-14T18:54:53.900812314Z' (node:22) Warning: [deprecated] In future versions, Strapi will stop reading directly from the environment variable API_TOKEN_SALT. Please set apiToken.salt in config/admin.js instead.
'2022-11-14T18:54:53.900829488Z' For security reasons, keep storing the secret in an environment variable and use env() to read it in config/admin.js (ex: apiToken: { salt: env('API_TOKEN_SALT') }). See https://docs.strapi.io/developer-docs/latest/setup-deployment-guides/configurations/optional/environment.html#configuration-using-environment-variables.
'2022-11-14T18:54:53.900832087Z' (Use `node --trace-warnings ...` to show where the warning was created)
'2022-11-14T18:54:53.964964931Z' [2022-11-14 18:54:53.963] error: 'bind EADDRNOTAVAIL %%IPADDRESS%%:1337'
'2022-11-14T18:54:53.964984876Z' Error: 'bind EADDRNOTAVAIL %%IPADDRESS%%:1337'
'2022-11-14T18:54:53.964987242Z' at listenOnMasterHandle (net.js:1398:18)
'2022-11-14T18:54:53.964989178Z' at rr (internal/cluster/child.js:138:12)
'2022-11-14T18:54:53.964991028Z' at Worker.<anonymous> (internal/cluster/child.js:105:7)
'2022-11-14T18:54:53.964992957Z' at process.onInternalMessage (internal/cluster/utils.js:48:5)
'2022-11-14T18:54:53.964994967Z' at process.emit (events.js:412:35)
'2022-11-14T18:54:53.964996757Z' at process.emit (domain.js:475:12)
'2022-11-14T18:54:53.964998501Z' at emit (internal/child_process.js:935:14)
'2022-11-14T18:54:53.965000256Z' at processTicksAndRejections (internal/process/task_queues.js:83:21)
Note:
%%IPADDRESS%%
in the above code block is a placeholder for the actual public IP address of my Caprover host machine.
I also tried using srv-captain--strapi
in the HOST
variable, and this time it used the Docker network's local IP address with the app's http port 1337
and produced the same set of errors:
'2022-11-14T19:06:00.880943567Z' (Use node --trace-warnings ... to show where the warning was created)
'2022-11-14T19:06:00.884912706Z' [2022-11-14 19:06:00.883] error: 'bind EADDRNOTAVAIL 10.0.1.61:1337'
'2022-11-14T19:06:00.884924569Z' Error: 'bind EADDRNOTAVAIL 10.0.1.61:1337'
Lastly, I tried appending the default http/80
and https/443
port numbers to the app's FQDN, but got the same errors.
The #120 merge to fix the localhost
issue also places the following in the post-deployment notice of the strapi-postgres
template, and points users to an issue in the deprecated Strapi Docker repo :
IMPORTANT: You need to add a config file manually to support the correct domain name. See this issue for more details: https://github.com/strapi/strapi-docker/issues/173
The accepted workaround seems to be to use docker exec
to attach a terminal to the container, and then use the following example within the ./config/server.js
file:
As @alexandrebodin mentioned you can take the following example: https://strapi.io/documentation/3.0.0-beta.x/concepts/configurations.html#example-3
And configure it with dynamic env variables:
{ "host": "localhost", "port": 1337, "proxy": { "enabled": true, "ssl": true, "host": "${process.env.PROXY_HOST}", "port": "${process.env.PROXY_PORT}" }, "cron": { "enabled": true } }
You may have to play with the boolean values as environment variables don't really support booleans (they are strings).
Originally posted by @derrickmehaffy in https://github.com/strapi/strapi-docker/issues/173#issuecomment-579136924
That appears to still be the accepted method for resolving the localhost
issue, although this is the workaround that I referred to earlier as "inelegant". I think requiring the user to use docker exec
generally isn't ideal for something called a "one-click-app", but if this is the only method for getting Strapi to work in Caprover then I will at least look into writing a single Bash command that can send awk
or echo
statements to the container via docker exec
such that this configuration can be achieved with a single copy/paste command from the host.