Technical steps
Locked
 
Administrator
|
Hello everyone! First of all, thanks again for being part of keeping Foodsoft in
the air, and making it better. The steps to take, I see as follows (feel free to adapt and add):
Hope this will get the discussion, preperation, and the work
going. Looking forward to hearing from you! Best, |
|
Hi,
> First of all, thanks again for being part of keeping Foodsoft in the > air, and making it better. thank *you*! > * Find a hosting provider. > o Input welcome! I'm currently running the Dutch instances on a > Leaseweb <http://leaseweb.com/> virtual machine, which has > worked pretty well in the past years, but perhaps you know of > better options. Would be nice to do something > green/sustainable, but in the past that costed more than the > foodcoops were willing to afford. Perhaps now, with more groups, > there is more room for that? Anyway, let's not get stuck on this too > long. I had good experience with UD Media in the past. That would be green energy at least. > o For comparison: I'm currently renting 2GB RAM / 2vcpu at > Leaseweb for two Foodsoft deployments serving 8 foodcoops in > total, setup as here [3]; 100MB in and out daily traffic on > busy days). The extra RAM is useful for loading large spreadsheets. https://www.udmedia.de/server/#managed-server 50 GB hard drive, 1 core, 4 GB memory, 100 GB traffic -> 40 € per month (probably annual payment). Sorry, the page seems to be available only in German. > o Did someone happen to mail Posteo for sponsoring? Yes, I mailed them, but there was no response (so far). Probably they're not interested. > * Make sharedlists <http://github.com/bennibu/sharedlists> ready for > deployment (required for shared suppliers). > o figure out which suppliers we'll need to import, contact them > for credentials, and configure. In Rostock we need access to TERRA articles, maybe we can use the credentials Benni used so far: http://terra-natur.com/ Robert |
|
|
We don't want a managed server probably. I can ask for root server costs, if you like: https://www.udmedia.de/server/#root-server |
|
Administrator
|
>> 50 GB hard drive, 1 core, 4 GB memory, 100 GB traffic -> 40 € per month
>> (probably annual payment). Sorry, the page seems to be available only >> in German. > We don't want a managed server probably. I can ask for root server costs, if > you like: > https://www.udmedia.de/server/#root-server Yes, @Robert I would like to see what udmedia.de offers us as a root server. I also expect that root access could become a requirement at some point. What about a virtual server? Hetzner (a well-known and reliable German provider) offers * 2 virtual cores * 50 GB SSD * 2 GB RAM * 5 TB traffic per month for 8.21 Euro per month (including taxes) [1]. [1] https://www.hetzner.de/virtual-server A dedicated server from Hetzner which we could virtualize ourselves starts at 46.41 Euro per month (including taxes) [2]. However, currently I think that this would be more than we need. [2] https://www.hetzner.de/dedicated-rootserver/matrix-ex I plan to go through all other points you @Willem and @Andre started as soon as possible (probably tomorrow). Regards, Julius |
|
Administrator
|
On 08-08-17 12:03, Julius [via foodsoft] wrote:
> >> 50 GB hard drive, 1 core, 4 GB memory, 100 GB traffic -> 40 € per > month > >> (probably annual payment). Sorry, the page seems to be available only > >> in German. > > We don't want a managed server probably. I can ask for root server > costs, if > > you like: > > https://www.udmedia.de/server/#root-server > > Yes, @Robert I would like to see what udmedia.de offers us as a root > server. > > I also expect that root access could become a requirement at some point. > What about a virtual server? Hetzner (a well-known and reliable German > provider) offers > > * 2 virtual cores > * 50 GB SSD > * 2 GB RAM > * 5 TB traffic per month > > for 8.21 Euro per month (including taxes) [1]. > > [1] https://www.hetzner.de/virtual-server > > A dedicated server from Hetzner which we could virtualize ourselves > starts at 46.41 Euro per month (including taxes) [2]. However, currently > I think that this would be more than we need. > > [2] https://www.hetzner.de/dedicated-rootserver/matrix-ex Interesting, it seems they also put some effort in sustainability. Other sustainable/green option would be Greenhost (2GB RAM, 20GB SSD, 2TB traffic, EUR 29 p/m). I could contact to see if we can get a reduced price (they've sponsored foodcoops before, not sure if they want to do that again). https://greenhost.net/products/virtual-private-servers/linux-vps/ - Willem |
|
|
In reply to this post by Julius
Am Tue, 8 Aug 2017 03:03:11 -0700 (MST)
schrieb "Julius [via foodsoft]" <[hidden email]>: > >> 50 GB hard drive, 1 core, 4 GB memory, 100 GB traffic -> 40 € per > >> month (probably annual payment). Sorry, the page seems to be > >> available only in German. > > We don't want a managed server probably. I can ask for root server > > costs, if you like: > > https://www.udmedia.de/server/#root-server > > Yes, @Robert I would like to see what udmedia.de offers us as a root > server. They point us to the smallest managed server and ask, what we need. As I remember: Very quick and personal support. |
|
|
In reply to this post by wvengen
> * Find a hosting provider.
> o Input welcome! https://www.netcup.de/vserver/ With eco-power. We will probably be using it for another project. |
|
Administrator
|
On 08-08-17 17:36, Robert [via foodsoft] wrote: > > * Find a hosting provider. > > o Input welcome! > > https://www.netcup.de/vserver/ > > With eco-power. We will probably be using it for another project. Interesting, pretty cheap, enough scale for proper tooling (remote console), while still using eco-power. So we now have, for a virtual self-managed server: PROVIDER RAM CPU HD BW EUR/m ECO Leaseweb 2GB 2 60GB 6TB 10 Leaseweb 4GB 4 80GB 8TB 18 Greenhost 2GB 1 20GB 2TB 29 y Greenhost 4GB 2 50GB 4TB 49 y Hetzner 2GB 2 50GB 5TB 8 Hetzner 4GB 2 100GB 8TB 14 Netcup 2GB 2 40GB 25TB 4 y Netcup 4GB 4 80GB 25TB 5 y Netcup 8GB 6 160GB 25TB 9 y Netcup looks like a good choice, with the current options I'd go for the 4GB RAM option and see if we can manage with that. - Willem |
|
Administrator
|
I'd like to make Docker the default/prefered/offical deployment method. Do you think it's ready to be merged into master? PR484 should do the trick. What kind of anti-spam measures do you need for SENDING mails? It's still in the "testing" phase and I wouldn't recommend to activate it on all production systems. I just enabled it for my foodcoop a few days ago (even the code is from february) and don't know about all possible cases which happen in the wild with all the different mail systems out there. In our setup in Austria that's just adding the offical Docker images to the docker-compose.yml. I can share our repository with whoever will setup Docker. Unfortunately it still contains some private data, which is the reason why I can not publish it on GitHub ATM. In our setup in Austria we use a haproxy Docker container in front of the foodsoft Docker container. The certificates are generated in a seperate container with certbot and are shared with the haproxy via a volume. In our setup in Austria we build our own "private" foodsoft image based on "public" image (published on Docker hub), which just adds the app_config.yml via COPY to the image. docker-compose.yml and the app_config.yml are managed via git. I'd suggest using Docker cloud and hooks where possible. So a push to the "config repository" (containing the docker-compose.yml) triggers a deployment. Merging those two and moving them to the foodcoops organization would be a nice step. We want to put some effort into sharing supplier articles (at least for Vienna) in the near future. Reusing as much as possible and having a clear basis would be great. I can recommend Netcup. I use it for one of my projects and it's works without any problems so far. -- Patrick |
|
Administrator
|
In reply to this post by Robert
Hey guys,
> I plan to go through all other points you @Willem and @Andre started as > soon as possible (probably tomorrow). I am sorry - was way too busy the last days: Today, I go on vacation with my daughter and I had to finish too many things. Netcup indeed looks fine. I like Docker a lot when I tried my first steps. The sharedlists from bennibu's github dockerfile was using some old version, so I did not get it running right away. Please feel free to go ahead with your plans if you find some time - finding a hoster, preparing the production setup with Docker, ... We from Beisswat do not need the feature to reply to messages by email. I will be back in two weeks. Best wishes, Julius |
Administrator
|
We are using this the "reply to messages by email" feature in our food co-op. |
|
Administrator
|
I don't think that we talk about the same feature. There is difference between setting the Reply-To header to the email of the sending user (what you mean) and setting the Reply-To header to a specific email which gets handled by foodsoft. If you would use that feature your Reply-To addresses would look like "slug.123.123.a1b2c3d4@app.foodcoops.net", but since there is no MX entry for that domain it can't work. - Patrick |
|
Administrator
|
I double-checked our emails and the Reply-To header is set to the email address of the user.
|
|
Administrator
|
In reply to this post by paroga
On 14-08-17 01:39, paroga [via foodsoft] wrote:
I like that. Created issue #491 for the move.I'd like to make Docker the default/prefered/offical deployment method. I think so (maybe one tiny non crucial bit).Do you think it's ready to be merged into master? Many e-mail providers (for reading) do spam checking in different ways, and this changes over the years. This includes making sure your host doesn't end up on a blacklist; proper reverse dns; SPF records; DKIM signatures; maybe more. My experience is that the more of these techniques you use, the higher the chances are your mail is not being seen as spam.PR484 should do the trick. Or use a mail sending service like Mandrill/Sendgrid/etc, but that costs. Agree.It's still in the "testing" phase and I wouldn't recommend to activate it on all production systems. I just enabled it for my foodcoop a few days ago (even the code is from february) and don't know about all possible cases which happen in the wild with all the different mail systems out there. I'm not very experienced in using Docker for production, so have not much clue how deployment using plain Docker, docker-compose, ... would look like in practice. How do security updates work (does that need updates on docker hub, or would you upgrade system packages within the docker image)? We could either use a single redis and database docker container for all setups, or put it in docker-compose (I suppose the latter would be more automated and hopefully less error-prone and configuration work).In our setup in Austria that's just adding the offical Docker images to the docker-compose.yml. I can share our repository with whoever will setup Docker. Unfortunately it still contains some private data, which is the reason why I can not publish it on GitHub ATM. Sounds like a good idea to do this in a separate container.In our setup in Austria we use a haproxy Docker container in front of the foodsoft Docker container. The certificates are generated in a seperate container with certbot and are shared with the haproxy via a volume. Does it make sense to use docker volumes for this? Git history on app_config (and env?) would be nice (but repo's need to be private - indeed, @Github or locally on server perhaps).In our setup in Austria we build our own "private" foodsoft image based on "public" image (published on Docker hub), which just adds the app_config.yml via COPY to the image. I do like the idea.I'd suggest using Docker cloud and hooks where possible. So a push to the "config repository" (containing the docker-compose.yml) triggers a deployment. Sharedlists is so old that I'd almost rather rewrite it (e.g. with something like rails admin). But to avoid more work, I think your suggestion is the best next step :)Merging those two and moving them to the foodcoops organization would be a nice step. We want to put some effort into sharing supplier articles (at least for Vienna) in the near future. Reusing as much as possible and having a clear basis would be great. Good to hear.I can recommend Netcup. I use it for one of my projects and it's works without any problems so far. |
|
Administrator
|
Ok, I see what you mean. How many email do you expect each month? There are free plans too and I don't see that we will reach the limits in the near future. Doing system updates inside a container is the complete wrong way. You ALWAYS regenerate the whole container. Building is usually automated, e.g. on Docker hub. I'd recommend using docker-compose! Then you do it the Docker way and you can reuse the existing and offical images. I can setup a minimal setup for the global instance, so you have something to start and play with it. I can add this to the sample docker-compose too, if there is an interest. app_config.yml is a configuration file, which should be version controlled. So a Docker volume is the wrong way IMHO. What kind of sensitive data do you see in the app_config.yml? In Austria we pass our database passwords via environment variables. So no sensitive data is stored in the file. Having a roadmap for that in the near future would be great, so we coordinate our work in Austria with all the other users. |
|
Administrator
|
In reply to this post by before
Great, we'll keep reply-to-foodsoft-by-email as something for the
future, also because it's not really production tested. And, now
we find, not enabledon app.foodcoops.net. On 16-08-17 14:50, before [via
foodsoft] wrote:
I double-checked our emails and the Reply-To header is set to the email address of the user. |
|
Administrator
|
In reply to this post by Julius
Thanks, Julius. Have a great holiday! - Willem On 15-08-17 10:44, Julius [via foodsoft] wrote: Hey guys, |
«
Return to foodsoft-global-ops
|
1 view|%1 views
| Free forum by Nabble | Edit this page |