Service Fabric - Use Docker Hub As Container Registry (existing .net Application)

Question

This is similar but different than what @emaia was attempting to ask here.

I'm looking at two things:

1) how to upload my .net containerized Service Fabric application to Docker Hub

It looks like based on this article when you are creating a SF Container project you can specify a Docker Hub location. I'm containerizing an existing .net application and wanting to use Docker Hub as my registry. I could containerize outsider of SF and then start a new project?

I will also be making code changes (bug fixes, enhancements ect) and will need to upload those changes to my Image, so i'm assuming after I've set Docker as my registry any time I deploy it tags the container and uploads to Docker Hub?

2) How to pull my container from Docker Hub to deploy to my onPrem Service Fabric Cluster. I think this is just a deploy like any other SF application but I wanted to verify. Are there any other gotchas out there?

Thanks,

Greg

UPDATE: Clarifying for @Diego Mendes

I'm not trying to deploy a SF "application" but once you add Orchestration Support to an existing .net application it turns it into a SF sln. I'm containerizing an existing .net 4.7 application and then building/deploying that container. I want to use SF as the orchestrator. It seems if I was to use Azure Registry instead of Docker Hub it would be much easier to manage this as you can easily publish to Azure registry, but there isn't a publish option to Docker Hub. The questions are:

1a) What is the best way to get that container into the Docker Hub Registry?

I think the worst case scenario is that I would need to upload the image outside of the SF sln using "Docker Push"? Then i start a new SF sln and use the container template to reference the Docker Hub location when creating the solution? Seems a little odd. I would then have two .sln files, solution A that houses the code and creates the image. Then post that image to Docker Hub and use a separate SF solution (solution B) that doesn't have the code to manage the container?

1b) How do i need to make updates to that image?

After i have uploaded my container image to Docker hub and then i make updates to the code how to upload the updates. It should be the same as however we upload it int he first place. If I have to do what i mentioned above then i would maintain the code in Solution A and use Solution B to orchestrate the image produced by Solution A? I'm hoping this is not the way to do it and i'm missing something.

UPDATE 2:

I think we are on the same page. Thanks for all the detail on the second part of the question. The heart of my question resides in the first part.

What I'm trying to clarify is how many solution files do I need to use. Do I need one Visual Studio Solution (Solution A) that compiles my code and creates the image and a then separate Visual Studio Solution (Solution B) only for Orchestrating that image? If that's the route I need to go then then follow up question is does the First solution even need to be a SF Solution or can I use any Solution that creates a Docker image.

The next steps is to manually upload to Docker Hub and see what changes in the SF solution when I point to that as my container source. Maybe I can figure it out and use just one solution to create and maintain that image.

Answer 1

1) You don't deploy service fabric application to docker hub, you deploy container images, don't try to associate SF application to the process, just think like a normal docker image. The SF Application is the process that happens after.

Regarding the versioning, try comparing this docker image to a non-containerized application, a non-containerized app you would build you application in a CI server(I.e.: VSTS, Jenkins) and then create an executable\deployable application that can be put in a zip file for example, and this file will have a name corresponding the version, generally the same as the build that generated it, a docker image will have a similar process, but the difference is that before you would put the files in a zip file, now you save on a image format.

Each image, will have a tag, that is very similar to the versioning you would have for a a non-containerized application, when you deploy a image, you identify the image by the tag specified during the build of the image, when you don't specify one it will be set to latest(that you should avoid, I describe why in the update below).

1a) Update

I don't understand your concern about creating the images, you can easily create and publish an image in docker hub using 3 simple commmands(Assuming you already have a docker registry account):

docker build -t $(dockerId)/$(imageName) //Create the image
docker login -u $(dockerId) -p $(pswd)   //Authenticate to you docker registry account
docker push $(dockerId)/$(imageName)     //Push the new image

The process is the same as you would do to a non SF image, check the docks here describing how to do on docker registry without service fabric, and here how you do using Azure Registry.

.

2) You do exactly the same way you would do in an Azure Cluster, and any other SF application, the link you provided describes it clearly.

2a) Update

To update container images, you would change the ServiceManifest.xml with the tag of the new version of your container image.

Unfortunately, the docs are not very clear about that, most of the samples, it uses an implicit tag, that is the lastest, when you don't define a tag it will consider always the latest, and if the image changes, it does not recognize it because the tag is the same.

You should always explicitly define the tag to your service, like this example, V1 is the tag for MyImageName:

<ServiceManifest Name="mySvcPkg" Version="1.0.0" ...
   <ServiceTypes>
      <StatelessServiceType ServiceTypeName="mySvcType"..
      </StatelessServiceType>
   </ServiceTypes>
   <CodePackage Name="code" Version="1.0.0">
      <EntryPoint>
         <ContainerHost>
            <ImageName>acrName.azurecr.io/MyImageName:v1</ImageName>
            <Commands></Commands>
         </ContainerHost>
      </EntryPoint>
   </CodePackage>
  <Resources>
    <Endpoints>
      <Endpoint Name="myEndpoint" UriScheme="http" Port="80" Protocol="http"/>
    </Endpoints>
  </Resources>
</ServiceManifest>

When you update the image, you add a new tag to it, like V2, also update the ServiceManifest Version, to show SF that the service package has changed:

<ServiceManifest Name="mySvcPkg" Version="2.0.1" ...
   <ServiceTypes>
      <StatelessServiceType ServiceTypeName="mySvcType"..
      </StatelessServiceType>
   </ServiceTypes>
   <CodePackage Name="code" Version="2.0.0">
      <EntryPoint>
         <ContainerHost>
            <ImageName>acrName.azurecr.io/MyImageName:v2</ImageName>
            <Commands></Commands>
         </ContainerHost>
      </EntryPoint>
   </CodePackage>
  <Resources>
    <Endpoints>
      <Endpoint Name="myEndpoint" UriScheme="http" Port="80" Protocol="http"/>
    </Endpoints>
  </Resources>
</ServiceManifest>

Regarding the authentication to a private repository, you add it to the ApplicationManifest.xml, in the ServiceManifestImport:

<ServiceManifestImport>
    ...
    <Policies>
        <ContainerHostPolicies CodePackageRef="Code">
            <RepositoryCredentials AccountName="myregistry" Password="=P==/==/=8=/=+u4lyOB=+=nWzEeRfF=" PasswordEncrypted="false"/>
            <PortBinding ContainerPort="80" EndpointRef="Guest1TypeEndpoint"/>
        </ContainerHostPolicies>
    </Policies>
    ...
</ServiceManifestImport>

When SF try to download the image in the repository defined in the ServiceManifest.xml, it will use the credentials provided in the ApplicationManifest.xml to authenticate in the registry.