search

MicrosoftDocs / azure-docs

Open source documentation of Microsoft Azure
https://docs.microsoft.com/azure
Creative Commons Attribution 4.0 International
10.28k stars 21.47k forks source link

What am I missing about Adding Service Fabric 'Container Orchestrator Support'? #14130

Closed SimonPuckeyAW closed 5 years ago

SimonPuckeyAW commented 6 years ago

So I add the above to a .netcore web api project, get a surprisingly slim Dockerfile and some SF looking config (but not as much as when I create a SF Container application from the template) and hit F5. The web api then debugs in IIS express (or self-hosted if I change the way it is run by the debugger). However I have no facility to then publish this container to my local service fabric cluster or debug the container while it is running in service fabric. Furthermore the dockerfile cannot be successfully built by the Docker daemon.

So at the moment I'm struggling to see what adding the service fabric orchestrator support actually does. I would be extremely grateful if someone could take the time to explain to me what I'm missing, no matter how obvious it probably is! Thanks Si.

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

mimckitt commented 6 years ago

Thanks for the feedback! We are currently investigating and will update you shortly.

mikkelhegn commented 6 years ago

@BigMorty @dbreshears You should see a Service Fabric Application project in your solution, which should be set as the startup project. Did that not happen?

SimonPuckeyAW commented 6 years ago

Hi @MikkelHegn, thanks for getting back to me so quickly.

I was attempting to add orchestrator support to a project in an sln where there was already an .sfproj. It seems in this scenario VS attempts to add a reference to the project requiring orchestrator support to the existing .sfproj. Im not sure how this affects the publishing of the container the sfproj was originally created for as havent tried it out.

My priority at the moment is identifying a project creation workflow that fits our needs and I'm still having a few problems with adding orchestrator support and then running containers on my local service fabric cluster. However I want to make sure I've identified any obstacles more precisely before I raise an issue so I dont waste anyone's time. Thanks again for help. I may be needing some more soon! :-)

SimonPuckeyAW commented 6 years ago

By adding SF orchestrator support to default .netcore api projects in their own individual solutions (and setting up the cluster as per the instructions above) I could debug both containers from VS. However I have tried to follow the guide regarding RESTful communication between the api's and I cant get WebApp1 to resolve the Service FabricDnsName of WebApp2.

For reference I used the following base image to run the applications in the container as unsurprisingly the base images specified in the auto gen'd Dockerfile didnt play nice with the .net core 2.1 api being hosted

I have trawled through github issues similar to mine but have not found a resolution. Any help in getting the app in 1 container able to resolve the sf dns name of the other container would be greatly appreciated as is vital to our developing with SF. thanks

SimonPuckeyAW commented 6 years ago

Hi @MikkelHegn, @MicahMcKittrick-MSFT . RE: Communicating between two services hosted on Local Service Fabric Cluster via Service Dns Name. I have pretty much hit a brick wall with this now so would appreciate some help if possible. I believe I have set everything up correctly as per the content on this page but I am not able to resolve the ServiceDnsName I have added to the Service attribute in the ApplicationManifest.xml, whether by pinging in .entcore 2.1 based container, ResolveDnsName on a windows server container deployed to the cluster so I can use powershell tools or in code using System.Net.Dns.

Please let me know the further information you require to isolate the problem and identify what I'm missing. Thanks

mikkelhegn commented 6 years ago

Just making sure you went over the Known limitations from this page. There are some caveats with DNS support on Windows 10. Had a different issue today here with some suggestions to try and troubleshoot: https://github.com/Azure-Samples/service-fabric-mesh/issues/19

SimonPuckeyAW commented 6 years ago

Thanks for suggestion will take a look.

Due to my lack of success communicating between containers with Service Fabric support, I went back to the Service Fabric Mesh containers I had already got communicating in my local cluster. While doing this I noticed the SF mesh application was automatically deployed with a Service Dns Name, based on {serviceName.applicationName}, and that this was also the format suggested by the Mesh docs for addressing the service in the local cluster.

Intrigued I debugged/deployed an SF (rather than SF mesh) api that I couldnt previously communicate with and docker exec'd onto a deployed SF Mesh api. Funnily enough I could ping the SF container's Service Dns Name from the Mesh container. Also from C# code running inside the SF Mesh api container I could call into the net core api (running in the SF container), by using Service Dns Name of the container as the domain name.

May not be important but also noticed that when debugging these containers on the local cluster the Mesh containers use the IP (assigned to them by Docker? they are visible when docker inspect anyway) whereas the SF application apparently cant be browsed to via the IP returned by docker inspect (this requires the machine name as domain name, as per the docs)

Dont really understand what the service fabric orchestration support and it's interaction with the local cluster is doing under the hood or what it is doing in addition to docker. However as far as DNS is concerned my experience is SF containers cant lookup the 'Service Dns Name' of containers running in the cluster but are discoverable by their own Service Dns Name by Mesh containers (that seem to run more closely with Docker).

SimonPuckeyAW commented 6 years ago

The service to service communication via dns name also works with sf containers when deployed to a remote cluster on azure portal. So my problem is only with sf containers running on a local sf cluster

mikkelhegn commented 6 years ago

To give you a better understanding of what's going on: SF Hosting (the sub-system responsible for hosting services) instructs the docker daemon about what should happen when you run a containerized service, same way it instructs the OS to start a process in the case it's not a container.

For networking its a bit more complicated. Processes live on the host, so shares NIC and network configuration with the host. Containers live on either a NAT network (shared physical NIC) or their own NIC (Open netowkring mode). Open network is not supported on OneBox (local clusters).

The Service Fabric DNS Service listen listens on the hosts primary NIC on the standard port. The service is responsible for translating DNS protocol to Service Fabric Naming protocol. For that to be successful, the service need to have a DNS name registered with the Naming service. this happens automatically in Mesh and Compose scenarios. For Mesh the dns name is service.app in compose it's service.composedeployment. For Native Service Fabric services, you have to specify the dns name you want to use.

When a container in SF queries for a dns entry, it first encounters the Docker DNS, then Service Fabric DNS Service. The Service Fabric DNS service will respond equally to any type of service that sends a request.

I didn't' quiet get in your last reply if you end up being successful or not?? :-) Can you share the yaml or xml files you are using for these services so I can better understand? Also there are a few scenarios where DNS traffic is lost (running in VMs) or the host NAT IP is not registrered correctly for the Service Fabric DNS service to find it.

theBlueclouds commented 6 years ago

I have a similar problem asked here https://stackoverflow.com/questions/52127453/service-fabric-container-api-not-loading-on-endpoint

SimonPuckeyAW commented 6 years ago

Sorry for delay replying @MikkelHegn , had a some other tasks to pick up. Also apologies if the info in my last message was confusing! To simplify: when I am running a container with Service fabric orchestration support on my local SF cluster any process running in the container (application code, ping etc) cannot resolve domain names. I think Im following guidance and dont think Im doing anything weird :-) i will post the manifest xml later

mikkelhegn commented 5 years ago

@MicahMcKittrick-MSFT - I suggest closing as this has gone stale for a long time.

SimonPuckeyAW commented 5 years ago

Yes it's fine to close this. We are no longer looking at Service Fabric or Service Fabric mesh for orchestrating our containers

danielwgrech commented 5 years ago

We have 2 solutions: one for Service A, and one for Service B. These have several related projects in each. We added Docker Support in each, and then created a separate solution which contains only the Service Fabric Application, in which we created "New Service Fabric Service -> Container" for both containers of Service A and B. This leaves us with a Service Fabric Application which can't be debugged because the only links it has is to Docker containers, not actual code.

My question is: how should we be maintaining the Service Fabric Application to support both local debugging (for both services at once which are in different solutions), and also for deployment? If I follow this article, I'd only be able to add Orchestration Support on one service independently of the other.

BigMorty commented 5 years ago

@danielwgrech If you are building a single Service Fabric application with two or more services, create a single solution that contains both service projects and add Container Orchestrator Support - Service Fabric to both. This should add a Dockerfile and service manifest to each of your service projects as well as add a Service Fabric (SF) project (.sfproj) to the solution. If you F5 with the SF project as the startup project, both services should be debugged within the containers. Be aware that only one of the services will be opened in a browser, this is controlled by the Launch Target property on the SF project.

danielwgrech commented 5 years ago

Thanks for your reply @BigMorty. I had managed to do what you suggested, but my question is whether it's possible to debug an SF application with services in different solutions. We would like to have a solution per "microservice team" or something on those lines, so that a developer doesn't have to open a mega solution with all projects inside. I guess we'll have to create a new solution which would have all projects combined, for SF debugging only.

BigMorty commented 5 years ago

@danielwgrech - I have a few ideas that might work for you, but I need a little more information about your scenario. Would it be possible for us to get on a Skype/Teams call to discuss more? If so, please send me an email at mike.morton@microsoft.com with a few suggested date/times.

MattHartz commented 4 years ago

@BigMorty I am unable to see "Service Fabric" as an option for Container Orchestrator Support. Only docker compose and "Kubernetes/Helm". Do you know if there is a configuration i am missing in my SF solution?

I am running .net core 2.2 web API service, along with many stateless services.

BigMorty commented 4 years ago

Sorry for the delay @MattHartz, I did not get a notification about this for some reason. You need to have the Service Fabric tools installed to see the SF orchestration option.

BigMorty commented 4 years ago

Can you please open a new issue with the details you included below? That will make it easier for an engineer to look into this issue.

Thanks, Mike

From: iulianb notifications@github.com Sent: Thursday, March 26, 2020 8:27 AM To: MicrosoftDocs/azure-docs azure-docs@noreply.github.com Cc: Mike Morton Mike.Morton@microsoft.com; Mention mention@noreply.github.com Subject: Re: [MicrosoftDocs/azure-docs] What am I missing about Adding Service Fabric 'Container Orchestrator Support'? (#14130)

@BigMortyhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBigMorty&data=02%7C01%7CMike.Morton%40microsoft.com%7C27e6f07e338c4dc214aa08d7d19a27b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637208332334191247&sdata=LMFlPzw4SnXBLbMjiNkARgtpJpJnwdKR9l%2FU%2FxcZnqk%3D&reserved=0 Sorry if I'm asking this in the wrong place but I have the same issue as @MattHartzhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMattHartz&data=02%7C01%7CMike.Morton%40microsoft.com%7C27e6f07e338c4dc214aa08d7d19a27b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637208332334201240&sdata=%2BeTTmyoO9Q1dY4UhHeEVO97JO6%2Bn4YQdcj8vebslV90%3D&reserved=0. I have Visual Studio Enterprise 2019 (16.5.1) with Service Fabric Tools installed, Microsoft Azure Service Fabric SDK (4.0.470) and still can't see the option in the menu.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F14130%23issuecomment-604495083&data=02%7C01%7CMike.Morton%40microsoft.com%7C27e6f07e338c4dc214aa08d7d19a27b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637208332334201240&sdata=rDPkog5AXwX45eqhbev7a%2BANg4CO5QffUfFLDVYn6Wo%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAHHKNRYDRG6WVURUOS47NDRJNX47ANCNFSM4FR775GA&data=02%7C01%7CMike.Morton%40microsoft.com%7C27e6f07e338c4dc214aa08d7d19a27b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637208332334211236&sdata=gguxr%2FNHM86NfJDzSP6EyvAScO0miwn%2FSkpB6bvlYeo%3D&reserved=0.