My environment is on Windows 10 Pro, docker desktop.
I follow well the instruction but encounter the error below:
ERROR: for standalone_squidex_proxy_1 Cannot start service squidex_proxy: Ports are not available: listen tcp 0.0.0.0:80: bind: An attempt was made to access a socket in a way forbidden by its access permissions.
ERROR: for squidex_proxy Cannot start service squidex_proxy: Ports are not available: listen tcp 0.0.0.0:80: bind: An attempt was made to access a socket in a way forbidden by its access permissions.
ERROR: Encountered errors while bringing up the project.
May I know if any clues on it to fix??
thanks a lot,
Michael
what is meant by ports for squidex_proxy is not available? I have the squidex running on the IIS port 80 already. Is it a conflict??
Yes, you can only have one application per port.
Yes, thanks, it is up now after turning off the default hosting port 80 by IIS/ docker ps
But how do I further confirm if Squidex is running?
Check the docker logs with "docker logs "
Yes, understood. I find those .env file have those “changeme” fields that must be filled while others are optional before running to build up the containers.
Checking for logs is needed, but how can I access the link like http://localhost:80 to local squidex installation on IIS. Frankly speaking, I am adopting Squidex to build the headless API call for backend CMS in a private hospital to use and using Azure Kubernetes Services, so the build up of related docker containers is a must.
I would be appreciated if more related resources on it is available to facilitate the development and architecture design for me to understand to proceed.
Thanks a lot, Sebastian for your prompt reply!
btw, both Windows container and Linux container are support for Squidex,
isn’t it?
I just feel lost, is there a way to add/ create the Web App Instance ?
I just follow the installation guide but don’t understand, where to create the Web App instance??
How do you mean that? In your previous screenshot you are using a name for your azure website that is taken. You have to choose another one.
It is resolved now, thanks. but
- Configure your storage account
Go to your storage account instance, choose Files and create a file share named ‘etc-squidex-mongodb’.
<-- where is ‘Files’ in storage account instance?? seem I cant find it
Choose Blobs and create a container named ‘etc-squidex-assets’.
Choose Access Keys and copy one of the keys for the setup of the MongoDB and one Connection String for the setup of the squidex asset store.
or may I ask what is the suggested quota when first assigned???
Is that the File Share you mean here below
It is “Blob service” now…I guess they have changed their menu items. I am not an Azure user and cannot provide detailed instructions how to use Azure.
Actually, I am a bit confused. I see your previous post reply mentioned that Kubernetes is also supported for Squidex deployment.
Does it imply it is possible to make for AKS(Azure Kubernetes Service)?
I have basic knowledge about docker and understand Kubernetes is an Orchestra of docker containers, are those pre-configured containers
jrcslestencrypt-nginx-proxy-companion
squidex/nginx-proxy
squidex/squidex:latest
mongo:latest
are also able to use for AKS deployment?
I am looking for the resources on guiding the AKS deployment, really appreciate if you can provide. Thanks
Hi,
I cannot provide guidance for all environments, because even in Azure you have multiple opportunities:
As a general guidance I would say the following:
1. How it is deployed?
Squidex is cross-platform and can be run on all major operation systems. It comes with 3 different deployments artifacts:
- Source Code: If you need to build it yourself.
- Binaries: If you have a Linux server or Windows server with IIS or another environments where Docker is not an option.
- Docker images. If you have an environment with docker support such as Docker. Docker-Compose, Swarm or Kubernetes or if you start with a new server from scratch.
2. Where to deploy Squidex?
This is usually defined what you are used with and what you have already in place? If all your other systems are running on Azure: Go for it. But personally I think Google Cloud is better and both of them are overpriced for small deployments.
For only 20% of the price you can get a very good setup on vultr. https://vultr.com
3. How to deal with external dependencies?
Squidex has three dependencies that need to be solved:
- Where and how do you setup MongoDB?
- Where do you store assets?
- How do you deal with https?
3.1. MongoDB
Again, this depends on the environments and skills. If you need stability and failover you need a replica set with at least 3 nodes (2 normal nodes and an arbiter).
Deploy it yourself
If you have the skillset to deploy MongoDB yourself, it is usually cheaper, but there are a few things to consider:
- Try to install MongoDB on a machine with SSD
- Ensure that your database server is not accessible from the public internet without username and password. It sound stupid but there have been a lot of leaks recently.
- Have a proper isolation between MongoDB and your other services, e.g. with cgroups (Docker) or VMs. It is not as important as the other points but MongoDB tends to consume a lot of Memory over time.
Deploy it with ready to use scripts
If you do not need full control you can use ready to use scripts. For Kubernetes there are helm charts available and the docker-compose file that is provided for Squidex also installs MongoDB.
Use a ready to use solution
If you have the money: Use MongoDB atlas or other managed solutions: It costs more but also provides services like backup, recovery and monitoring.
Storing assets
If you work with assets in Squidex you have to let them store somewhere. Squidex provides several providers:
-
File system: The fastest, but if you use Docker you need to ensure that you have a volume for your assets, otherwise they might get lost after restart.
-
Cloud Providers: Azure (Blob Storage), AWS (S3) and GCE are supported. Best and cheapest if you are already using one of these providers.
-
MongoDB: MongoDB has a solution for files called GridFS. You can store your files in your MongoDB database. Not as fast as the others but works pretty well and makes backup easier as you only have to backup your MongoDB databases.
HTTPS
Squidex needs to run with https. There are so many reasons for that. And again there are several opportunities:
- Use a reverse proxy, e.g. nginx with a custom certificate or lets encrypt. I follow this approach for docker-compose templates.
- Use a Kubernetes ingress.
- Use a CDN provider like Cloudflare.
- Buy a certificate and setup the certificate directly in your installation, e.g. read this: https://docs.microsoft.com/en-US/aspnet/core/security/docker-compose-https?view=aspnetcore-3.1
- Use a service from your cloud provider.
Thanks Sebastian/
well, I make it step by step using your docker approach installation for squidex. But I check the backend nginx server outcome http 400 error / while the letsencrupt nginx component encounters the error I do not understand. The last image is the configuration I used.
so my questions are how
- can I access the squidex admin UI like one using IIS approach … http://localhost:80
locally to verify my docker installation is in success and function??
- I use your provided domain “cloud.squidex.io” as the value for SQUIDEX_DOMAIN/
so is that mean App/Blog/Profile/Identity settings are on your remote cloud.squidex.io host?
- I wish to make the development locally, can set “localhost” for SQUIDEX_DOMAIN, but it seems to not allow (issue of getting certificate on letsencrypt). Is it possible to make?
Thanks for your advice
I find the hosts are mapping automatically for me / for windows 's host file.
How can I edit it to make my local access and development possible?
btw, I find neither vi nor nano are available for editing the web.config file for “squidex container” (just realized it is a linux container, seem limited functions)
/
- would you advise default one to edit it ?
- as supposed, appsetting.json is needed to customise like using “IIS approach”, but again can I make a “appsetting.Produciton.json” file to ovrerride ?
There are some fundamental errors:
- you cannot make modifications in the container itself as images are read-only. and all changes might get lost. Therefore containers are usually configured with environment variables or use a custom appSettings.Production.json
- Lets-encrypt issues a real certificate, so you need to ensure that you have a domain that is pointing to your server.
- You cannot use cloud.squidex.io, it is not your domain. SQUIDEX_DOMAIN must point to the actual domain, e.g. localhost or your custom domain. If localhost:80 is not available you need to map to another port.
If you want to run Squidex under localhost you can try the docker-compose file without nginx and lets encrypt. If you
- you cannot make modifications in the container itself as images are read-only. and all changes might get lost. Therefore containers are usually configured with environment variables or use a custom appSettings.Production.json
<–ok so I need to amend to add settings in docker-compose.yaml file to do so?? rather than modifying inside the container and restart
2. Lets-encrypt issues a real certificate, so you need to ensure that you have a domain that is pointing to your server.
3. You cannot use cloud.squidex.io, it is not your domain. SQUIDEX_DOMAIN must point to the actual domain, e.g. localhost or your custom domain. If localhost:80 is not available you need to
