Open alimakki opened 6 years ago
@alimakki the reasons that aliyun doesnt work out of the box are found in #889. I was working on adding a way for people to manually set the external IP as a config before provisioning that would work in a general way, and teaching myself a little ansible along the way. At the time, I could not find a aliyun module for ansible, but @nopdotcom seems to have found one. I had not yet come up with good solutions for the other issues.
As i've mentioned elsewhere, Aliyun is one of the only big VPS providers that has an HK data center, and it has excellent peering with mainland china. I often run even unencrypted traffic via HK because trying to access anything outside of mainland china runs so much faster via HK.
I'd really like to handle this integration, since I've been a waste of a core team member on this project! 😃
@hadifarnoud if you manually fix configurations and start services that fail to start at boot as I documented in #889 you should be able to get a working instance on aliyun until I get this done.
@nopdotcom have you already made progress on this? Maybe we could do some pair programming on it?
@nickolasclarke : No progress quite yet...I still need to set up my account! I'm working on it though.
More to the point, adding this is more interesting to me than finding holes in the Docker documentation; hopefully I can get something done tomorrow before the power (probably) goes out. :-)
I've taken a stab at this and nearly had it working properly but I'm dropping development.
The most important reason is:
Other outstanding issues on my branch:
awk
could solve this. mirrors.cloud.aliyuncs.com
) are not resolvable by outside DNS servers. You must use the DHCP-provided DNS or update the sources.list to an external mirror. I would probably use the outside-resolvable domain to these same mirrors, mirrors.aliyun.com
. However, this is problematic if you are doing a pay-as-you-go data transfer plan.ecs.xn4.small
If the issue around the data-transfer package can be resolved, than I think that the final three can also be resolved easily. However, without a cheaper data transfer package available, the best choice is to use the existing playbooks to provision a localhost/existing server. We could add a sub-playbook for localhost and/or existing server roles that would provision the security groups for you, and either remove the DNS changes, or update the repos. However, this seems half baked and its probably better to just wait until there is proper API support for everything you need for aliyun instead of this.
If someone has answers to how to address these issues, than we can resolve and merge my branch. You can see it here
Thanks @nickolasclarke. I think in the mean time I use localhost/existing server playbook for hetzner cloud in the meantime. It's cheap enough :)
@hadifarnoud if you need help getting an aliyun instance up, I'm happy to help!
@nickolasclarke what would be the best way to contact you?
@nickolasclarke I recently noticed a change in the entry level packages at Aliyun. The other day I was browsing their pricing for something they called a Simple Application Server. A bare bones Ubuntu 16.04 instance with minimal resources in HK come to only $3.40 per month with 1TB of data transfer included. They have higher tiers also at pretty cheap rates. I have been paying $9 a month for one of their old packages with a simple shadowsocks server. I want to try Streisand instead.
I don't know about any changes in their API support for provisioning instances, but I think you can manually reset/destroy/recreate instances after purchase without having to incur repeat charges.
I just tried the other day to do a standard "Existing Server (Advanced)" install on a manually provisioned minimum spec Simple Application Server in the HK region and encountered the same problem as you listed here:
- Aliyun's internal ubuntu mirrors (
mirrors.cloud.aliyuncs.com
) are not resolvable by outside DNS servers. You must use the DHCP-provided DNS or update the sources.list to an external mirror. I would probably use the outside-resolvable domain to these same mirrors,mirrors.aliyun.com
. However, this is problematic if you are doing a pay-as-you-go data transfer plan.
During the course of installation I would get errors, when the openconnect task came up unable to resolve the resources on (mirrors.cloud.aliyuncs.com
)
Is there a quick work around to get the installation to complete? I don't really understand how to change the config to point to the new mirrors as you mentioned:
You must use the DHCP-provided DNS or update the sources.list to an external mirror. I would probably use the outside-resolvable domain to these same mirrors, mirrors.aliyun.com.
Can you point me in the right direction? Thanks for the help!
@mikecui Thanks for reaching out! I'm looking at those new packages and it seems its at least 4.50 a month?
Re: openconnect not being able to reach mirrors.cloud.aliyuncs.com
is probably due to streisand setting your DNS server to google's 8.8.8.8 servers. If you comment out that task, I think it should just use the DCHP-given DNS server (Which is an internal aliyun server) and it will work. However, package upgrades will eat into your data transfer plan since it will be going outside aliyun's network to pull them. This may not be an issue for you.
If you are only running shadowsocks, I might suggest running outline instead of streisand, given that things have slowed down a lot lately and they appear to be tracking changes to shadowsock better.
@nickolasclarke Thanks for the tip! I will look for the the places where the tasks set the DNS to Googles DNS and comment them out and give it a whirl.
I noticed that discrepancy too for the $4.50 a month on the pricing page. When I am logged into my Aliyun account I can see the $3.40 when I add the product to my cart. I think the $4.50 assumes you are using a managed hosting image, it still seems to be $3.40 for a clean Ubuntu image. This might be an oversight on Aliyun part. Thanks again @nickolasclarke I'll let you know if I have any problems. Best Regards,
Mike
@nickolasclarke I have been able to successfully do an "existing server" install on a $3.40 per month Simple Application Server in their Hong Kong data center.
I have only tested the Shadowsocks service at this time but I don't recall any serious warnings or error messages during the install regarding the other features besides probably expired checksums on mirrored clients. Also, I had to open up ports through the server management interface on Ali to allow connections for Shadowsocks.
Under global_vars/globals.yml I changed the second upstream DNS server to one of Ali's internal DNS server. That's it.
upstream_dns_servers:
- 8.8.8.8
- ali.internal.DNS.server
To get the internal DNS server, I just did an nslookup mirrors.cloud.aliyuncs.com
after freshly spinning up the new server.
I tried commenting out all three lines entirely, and just the two server IP lines, and 127.0.0.1, but the installer didn't like missing vars and also apparently missing ip values. Granted, security minded folks might not be excited to be using an internal Ali DNS server for downloading packages, but during the course of my debugging I got the impression that mirrors.cloud.aliyuncs.com is simply not resolvable externally. I think you mentioned that in your post. I saw some posts on the web for a different FQDN that supports external resolution. Maybe that's the proper solution instead of this workaround.
If you guys think it's worth it, I don't mind raising some issues for the expired signatures and possibly doing something to help add Alicloud support to the playbook?
Best Regards, Mike
@mikecui great work! A real derp on my part to not simply add the second internal DNS server. I'm not sure why I didnt think of that. It'd be interested to know if the "different FQDN" counts traffic against your data transfer plan. Also, imo, if you are using alicloud for your provider, pulling packages from their internal mirror is no less secure than using the service at all. It is fully compromised, given they control the hardware. Using a mainland controlled provider is not the right solution if you want full security.
Any help you are willing to put forward to add alicloud support is welcome. I've not looked into this since my original work over a year ago. However, I suspect several of the main blockers to adding full support still exist.
Aliyun does not support deploying their starter package instances programmatically. You can recreate most of this yourself, depending on the region, except the data transfer packages, which means the only option is to buy a rather expensive transfer plan, or pay as you go. This leads to inconsistent and significantly higher costs, which differs from all the other providers. There is not an easy way around this up to now that I know of.
Subscription instances cannot be released and recreated. You would have to rely on a snapshot or drop the disk and attach a new one. This grates against the idempotent nature of Ansible. If for whatever reason your instance fails to provision properly, you cannot simply destroy and start over, unless you want to pay ~5.00 USD a pop.
can these new packages be spun up programmatically? Previously, they could not be done either with the Aliyun module for ansible, (which did not have full API coverage when I last used it), or using the raw API.
Are Simple Application Server's pre-paid monthly like the starter packages are/were? Or do they charge per second/minute? If the former, it becomes very expensive, very quickly, if you want fully ephemeral servers. You are stuck using the 'existing server' manual workflow once you deploy if you don't want to pay $3.40 a pop. If the latter, that's an improvement!
If you'd like to dig into some of those existing issues, we could get this to the point of pulling it in, but I suspect that simply using the 'existing server' flow with some documentation on the instructions alicloud are probably the best solution.
Costs:
I can't remember off the top of my head I think the metering it's in the sales materials, but I remember that Ali Simple Application Server charges for traffic in a standard manner as their ECS instances for downstream and upstream use (I think whichever is larger so usually downstream). So if we use Ali's repositories I don't think they treat it any different and we will be charged for the package transfer data.
The $3.40 a pop is all inclusive. It's a pay-as-you-go monthly charge and includes 1 Terabyte of data transfer per month at 30 MBit bandwidth.
$3.40 a pop also has a downside. When I was setting up my server it incurred the $3.40 each time you spin up a new instance regardless if you destroy it only an hour later during testing. I haven't gotten around to asking Ali support for a prorated refund b/c I think their policy is no refunds so I probably won't bother. I plan to just to eat the charge for my first try $3.40. So be mindful of instantiating a server even just for testing as they won't refund you. I think I did it to get a new IP that wasn't blocked. I think the IP of my first try instance was blocked from where I am.
Automated Install w/ Ansible:
I looked for/over the dev API briefly and I think you are right as there is no raw API that I found for spinning up instances for users. So I guess automated install is not possible at this time until they APIify.
I think a better documented 'existing server' install is probably the way to go. I'd be happy to document what I did and submit for review.
However...
I hate to admit but I am not actually using Streisand at the moment on my server. :-). My server IP got blocked during the recent sensitive time and since I use my server for just personal use I am using this technology instead and an upgraded kernel w/ BBR for congestion control. Works great for me for my use case(YouTube@1080p, browsing) for now.
Regardless of what proxy flavor we use. I still think Ali is the best value for performance I have seen shopping around as of late, security issues notwithstanding. I am also getting intermittent IP blocks sometimes from different telco carriers but not a nationwide block. I feel like after each years sensitive time their heuristics are getting better at detecting traffic and blocking IPs. Where as before I generally use PAC for traffic routing, I am sticking with Global routing as of late hopefully to stay under the radar. A cat and mouse game...
Thanks for the feedback!
Requested by @hadifarnoud