I'm trying to perform a VIP swap via the azure portal and I'm getting the error:
Windows Azure cannot perform a VIP swap between deployments that have a different number of endpoints.
I looked closer and I DO see difference in # of endpoints (2 in production vs 3 in staging).
Production:
Input Endpoints
OUR.API:168.62.21.50:80
OUR.API:168.62.21.50:3389
Staging:
Input Endpoints
OUR.API:168.62.22.55:80
OUR.API:168.62.22.55:3389
OUR.API:168.62.22.55:8172
Port 80 is web and 3389 is remote desktop. So far so good. Where is that additional port, 8172, coming from? Nothing in the application listens to anything other than port 80. Plus the applications in the staging and production areas are almost identical - so it's gotta be the framework. Any steps in narrowing this down?
[edit]
Also, my role's ServiceDefinition.csdef has just one endpoint defined:
<Sites>
<Site name="Web">
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="http" port="80" />
</Endpoints>
"Where is that additional port, 8172, coming from?"
It is from WebDeploy being enabled in the publishing settings
Long answer:
I parsed the entire configuration one by one between the staging and production, here is what I found:
Your publishing settings are saved to
<azurerole>\Profiles\<yourprofilename>.azurePubxml
My production deployment had
<AzureEnableWebDeploy>True</AzureEnableWebDeploy> while my staging deployment had <AzureEnableWebDeploy>False</AzureEnableWebDeploy>
The Azure infrastructure then looks that up and opens port 8172 to enable WebDeploy on the staging roles. So that's why the endpoints are different despite no new endpoint defined in the ServiceDefinition.csdef file.
I'm not sure why having different number of endpoints should prevent an Azure Publication itself.
For me the issue was that my PROD instances had RDP enabled and the STAGING did not. So "RDP" was the endpoint that was different.
Related
I am in the process of evaluating moving a very large Azure Cloud Service (Web Role) microservice architecture to AKS and have been working through the necessary code and build changes to support it.
In order to replicate the production environment locally for the developers, we run nginx on the host with SSL offloading and DNS (hosted in Azure) A records pointing to 127.0.0.1. When running in the Azure Emulator, the net affect is the ability for both the developer to visit the various web front ends in their browser (i.e. https://myapp.mydomain.dev) as well as hit the various API's in the solution (Web API 2) in Postman/cURL, etc.
Additionally due to how the networking of the Azure Emulator works, the apps themselves can resolve each other through nginx on the host (i.e. MVC app at https://myapp.mydomain.dev can obtain a token from the IdP web API at https://identity.mydomain.dev and then use that token at the API at https://api.mydomain.dev). This is the critical piece and the source of my question.
All attempts at getting the containers themselves to resolve each other the same way the host OS can (browser/Postman, SSL offloading via nginx) have failed. Many of the instructions out there are understandably for linux containers but having adapted the various networking docker-compose settings for the windows container equivalent have not yet yielded an success. In order to keep the development environments aligned with the real work systems, which are tenantized and make sure of the default mapping in nginx to catch all incoming traffic and route it to a specific user facing app/container, it is not as simple as determining a "static" method of addressing these on startup and why the effort was put in to produce the development environments we have today.
Right now when one service (container) attempts to communication with another, it ultimately results in a resolution error as all requests resolve to https://127.0.0.1 due to the DNS A records hosted in Azure for the domain. Since this migration will be a longer term project, the environments need to co-exist so changing the way that DNS is resolved (real DNS A records pointing to 127.0.0.1), host running nginx and handling SSL offloading to the various webroles normally running in the Azure Emulator is not an option.
Is there a way (with Windows containers) to either:
Allow the container to utilize nginx on the host OS transparently (app must still call the API at https://api.mydomain.dev), which will cause the traffic to be routed properly to the correct container/port defined in the docker-compose file?
OR
Run nginx on each container, allowing each container to then resolve and route appropriately without knowing the IP of the other container, possibly through an alias which could be added to the containers nginx.conf before the service starts?
The platform utilizes OAuth2/OIDC and it is critical to maintain the full URL to the other services from the applications perspective. Beyond mirroring production and sandbox environments, this URL's are utilized for redirect URL and post logout redirect URL validation among other things so using "https://myContainerNameForOtherContainerAlias" is not a workable solution.
Will I have the same problem when setting up the AKS environment as well?
I cant seem to correctly setup Reverse Proxy for my Jenkins with IIS.
Everything works correctly however I cannot get that message to disappear! Running the "administrativeMonitor/hudson.diagnosis.ReverseProxySetupMonitor/testForReverseProxySetup" is not returning a 200.. but in fact a 404.
I also use the plugin Blue Ocean, I noticed that when running pipelines when accessing Jenkins via my Reverse Proxy, I cannot see the live updates!! I dug into this and found out that it usually is from a bad Revery Proxy setup. If I access jenkins via localhost, I can see Blue Ocean Pipeline updates live, so something must be setup wrong!
What I got:
Windows Server 2019 Datacenter
IIS 10
I have HTTPS setup, so my aim is: Go to jenkins.example.com, it will redirect to https://jenkins.example.com which in turn is a reverse proxy loading jenkins.
My web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules useOriginalURLEncoding="false">
<!-- Enforces redirection of all HTTP traffic to HTTPS -->
<rule name="Enforce HTTPS" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="off" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
</rule>
<rule name="ReverseProxyToLocalJenkinsRule" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="on" />
</conditions>
<action type="Rewrite" url="http://jenkins.example.com:7070/{R:1}" />
<serverVariables>
<set name="X-Forwarded-Proto" value="https" />
<set name="X-Forwarded-Port" value="443" />
<set name="X-Forwarded-Host" value="{HTTP_HOST}" />
</serverVariables>
</rule>
</rules>
</rewrite>
<security>
<requestFiltering allowDoubleEscaping="true" />
</security>
</system.webServer>
<system.web>
<httpRuntime maxUrlLength="4096" />
</system.web>
</configuration>
This seems to be the best working reverse proxy I can obtain, following jenkins tutorials usually leads me to login issues (URL doubling up, i.e: example.com/https://example.com)
P.s, this is the latest windows server image out there and is a clean base build.
I ran through many tutorials however nothing has solved this issue, any advice is muchly appreciated.
I also want to point out that I have one server with Jenkins installed and IIS, Jenkins is accessible at localhost:7070 on the server locally. I also have edited my hosts file on the server to:
127.0.0.1 jenkins.example.com
Where the jenkins.example.com is an actual subdomain/domain pointing to the public IP of my server.
So when I ping: jenkins.domain.com on the server locally.. it returns 127.0.0.1. If I ping outside of that server, I.e.. on my PC, I get the public IP.
EDIT:
I have Application Request Routing installed and below is my config:
I just spent 6 hours of my life debugging this one, and I hope if some poor soul finds this page, as I did, my answer will be of some help. Almost identical situation to the original question, but for the sake of being thorough, I'll detail my exact situation, and my exact solution:
I am running a Windows Server 2019 Datacenter on AWS EC2
My EC2 instance lives under an Application Load Balancer which automatically redirects all http traffic to https, but forwards requests to the server using http only. That is, the user is always connected to the load balancer using https, but the load balancer connects to the server using only http
On that server, I am running Jenkins locally at localhost:8080
I want to reverse-proxy jenkins.mydomain.com to localhost:8080 without configuring SSL at the IIS level
I have read through ALL of the tutorials available on Jenkins' website, other websites with similar "IIS Jenkins Reverse Proxy" tutorials, and all related StackOverflow articles. NONE have solved my issue, and most want you to configure an SSL cert at the IIS level.
Also, I was getting the same mysterious error of the URL doubling up like jenkins.mydomain.com/"http://jenkins.mydomain.com:80"
Here is my exact configuration that solved the issue:
Obviously, you need to configure everything on AWS correctly. If you're not using AWS, make sure that your configuration is comparable.
EC2 Instance with security policy allowing incoming connections on port 80
Application Load Balancer redirects http requests to https, and forwards https requests to your EC2 instance on port 80
Application Load Balancer configured with SSL certificate
DNS configured to direct jenkins.mydomain.com to your Application Load Balancer
As with other tutorials, you must have ARR installed for IIS
UNLIKE other tutorials, do NOT add 127.0.0.1 jenkins.mydomain.com to your hosts file. If you have added it, remove it.
In IIS, Application Request Routing Cache > Server Proxy Settings
Enable Proxy: checked
Reverse rewrite host in response headers: checked
THIS DIFFERS FROM OTHER TUTORIALS, AND IS ULTIMATELY THE KEY THAT CAUSED MY SETUP TO WORK
In IIS, Default Website > Request Filtering > Edit Feature Settings
Allow Double Escaping: checked
In IIS, Default Website > URL Rewrite > Add Rule(s) > Blank Rule
Name: Jenkins Rewrite
Pattern: (.*)
Conditions: {HTTP_HOST} matches .*jenkins.mydomain.com.*
Server Variables: None
Action: Rewrite http://localhost:8080{UNENCODED_URL}
Note that THERE IS NO NEED to include an http to https redirect rule here. If you have one, I don't think it'll hurt anything, but don't get caught up by thinking this is important, as other tutorials suggest.
In IIS, Configuration Editor > system.webServer/rewrite/rules
useOriginalURLEncoding: False
In Jenkins (which you may need to access via loacalhost:8080 at first), Manage Jenkins > Configure System
Jenkins URL: https://jenkins.mydomain.com/
In Jenkins, Manage Jenkins > Configure Global Security
Enable Proxy Compatibility: checked
And that's it! It's possible that some of those steps (especially 9 and 10) may be unnecessary, but in the process of getting to where I am now, those values were ALREADY set, and once it started working I didn't want to change ANYTHING!
Again, the major breakthrough for me was to ENABLE "Reverse rewrite host in response headers".
Edit: Also, by the way, once you get everything working, feel free to just hit the "Disable" button on the Jenkins warning about your reverse proxy configuration being messed up. I think that this situation, and the resulting configuration to make it work, is so non-standard that Jenkins doesn't recognize that it is, in fact, working.
Is it possible to run Quartz.Net in an Azure WebJob and communicate with it using a RemoteClient proxy? If so, how could I figure out what the address would be?
<quartz>
<add key="quartz.scheduler.instanceName" value="RemoteClient"/>
<add key="quartz.scheduler.proxy" value="true"/>
<add key="quartz.scheduler.proxy.address" value="tcp://127.0.0.1:555/QuartzScheduler"/>
</quartz>
I know that Azure has its own scheduling mechanisms, but my application has to run in both Azure and Self-Hosted environments.
The Azure WebJob has the same sandbox limitation as the Azure Website in which it cannot open an arbitrary port and listen on it.
One possible way to communicate with a WebJob is via persistent queues (like Azure storage queue, servicebus queue or any other).
I am using the New Relic monitoring service with the .NET agent. It runs on the production server.
However, I also get statistics from my local machine when I am testing/developing the application. I used the New Relic Server Monitor Configuration tool to stop the service, and also disabled it with services.msc. But I still see my local machine in the "servers" section when I check my application on newrelic.com.
What should I do (either in my application or with my machine) to stop this?
The Windows Server Monitor is a different application from the .Net Agent. You will need to disable the .Net Agent in order for your development system to stop sending data to your application. If you don't want to have the .Net Agent run at all on your development system you can alter the newrelic.config file in %ALLUSERSPROFILE%\New Relic\.NET Agent to disable it by changing the following:
<configuration xmlns="urn:newrelic-config" agentEnabled="true">
to
<configuration xmlns="urn:newrelic-config" agentEnabled="false">
This has the advantage of being set globally, but if you want to turn it on and off per application you can add the following in the web application's web.config:
<appSettings>
<add key="NewRelic.AgentEnabled" value="false"/>
</appSettings>
I have multiple Azure service configurations (ServiceConfiguration.(Release/Local).cscfg. I simply removed the licensekey from the Local configuration. And uninstalled the two agents on my Windows machine (via Change or Remove a Program).
When I ran the project again locally, it didn't report, so all is good ;)
I've got an app that I am trying to run on my dev system under IIS Express from VS2010 that I need to use port 80 for, but I can't get it to work. I've looking up information talking about port 80 being reserved.
http://learn.iis.net/page.aspx/1005/handling-url-binding-failures-in-iis-express/
But even after doing that I still get an error from vs2010 that says
"Unable to launch the IIS Express Web server. Port '80' is in use."
I don't know what else to try. I've used Process Hacker to track down port 80 and it seems to be used by System running on process ID 4, which is the NT Kernel and System process. I don't know if that would prevent me from using the port though. I thought maybe that was a result of http.sys holding that port so nothing else could use it?
I did managed to get IIS Express to run on port 80 by modifying the default binding of the C:\Users\[MyUser]\Documents\IISExpress\config\applicationhost.config file, and while I can start IIS Express manually this way, VS then gets an error because a binding already exists on that port. So I change it back to 8080, create the virtual directory using the button within VS2010 (which I'm guessing is the same as entering a site binding) but I still get an error when I go to debug the application. Is there something hardcoded in VS2010 that won't let it start IIS Express on port 80?
UPDATE & FIX: Ok, so I found a few more things to check and I did resolve my problem but not completely. One post suggested making sure I did not have SQL reporting services installed as it can monitor on port 80, I used to have it installed but not anymore and was not the problem I was encountering. I did however realize that I have WebDeploy installed. It was bundled with the VS2010 SP1 bundle from the Web Platform Installer. This is fine as I do want the client tools from WebDeploy, but it also installed the agent on my system which was monitoring on port 80. I went to my list of services and stopped the Web Deploy Agent Service. Soon as I did this I can now use port 80 for IIS Express from within VS2010.
New Issue related to running on port 80 in IIS Express
However my application is an MVC3 App, and I've run into a problem because the MVC3 isn't capturing my request at all, so It's not firing my controller actions or anything like that, but a txt file in the root of my app can be reached so I know it's my site that IIS Express is serving up. Anyone have any issues running an MVC3 (I don't know if it's exclusive to MVC3 or not) in IIS Express on port 80?
Just posting my own answer for this problem so I can mark the question as answered.
Check http://learn.iis.net/page.aspx/1005/handling-url-binding-failures-in-iis-express/
Disable the Web Deploy Agent service if you have it installed.
in my case i solved the issue by stop "SQL Server Reporting Services"
you can find it in
control panel -> sevices
THANK YOU very much for you discovering of the 'Web Deploy Agent' service! This is something that only recently got turned on as I had all this working perfectly and just today installed the updated version of IIS Express, and ran into the exact same problem with port 80. So now that I have turned off the Web Deploy agent, my system works correctly again.
As for ASP.NET MVC3, that works great for me on port 80 and port 443. It was quite a bit of work to bind both those ports so that IIS Express was able to use them as a normal user (most of it from the link you posted above), and to install the SSL certificate we use. I manually created all the entries in my applicationhost.config file to get this working, and the appropriate sites section is below:
<sites>
<site name="PHP: A Main" id="2144116512">
<application path="/">
<virtualDirectory path="/" physicalPath="C:\var\www\amain\www" />
<virtualDirectory path="/images" physicalPath="C:\var\www\images" />
</application>
<application path="/admin">
<virtualDirectory path="/" physicalPath="C:\var\www\amain\www\admin" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:80:test.amainhobbies.com" />
<binding protocol="https" bindingInformation="*:443:test.amainhobbies.com" />
</bindings>
</site>
<siteDefaults>
<logFile logFormat="W3C" directory="%IIS_USER_HOME%\Logs" />
<traceFailedRequestsLogging directory="%IIS_USER_HOME%\TraceLogFiles" enabled="true" maxLogFileSizeKB="1024" />
</siteDefaults>
<applicationDefaults applicationPool="Clr4IntegratedAppPool" />
<virtualDirectoryDefaults allowSubDirConfig="true" />
</sites>
Note that my site is a combined PHP and ASP.NET MVC3 site, as we are in the process of re-writing the entire thing to run on ASP.NET MVC3, so most of the site is still PHP but lots of new stuff is now running ASP.NET MVC3, and that stuff works for me.
Does your IIS Express work properly with MVC3 outside of Visual Studio, or is the MVC3 stuff just not working at all?
I didn't have the Web Deploy Agent installed but ran into this issue. You can also fix this by running this command to find out which application or service is using the port and then trace it down in Task manager.
netstat -o -n -a | findstr 0.0:80
Then open Task manager, go to Processes, click the checkbox "Show processes for all users" and then click the View menu and Go to the Columns, add the PID column.
Match the Process ID from the netstat command to the PID in task manager and you will find the service or application that's using the port.
That solution helped me.
On Windows 7 or Windows Vista, from an elevated command prompt, run the following command:
console
netsh http add urlacl url=http://localhost:80/ user=everyone
This command will allow any user's application (including your own IIS Express instances) to run using port 80 without requiring administrative privileges. To limit this access to yourself, replace "everyone" with your Windows identity.
Taken from that source -> https://learn.microsoft.com/en-us/iis/extensions/using-iis-express/handling-url-binding-failures-in-iis-express