Service Fabric - использовать Docker Hub в качестве реестра контейнеров (существующее приложение .net)

Question

Это похоже, но отличается от того, что @ emaia пытался задать здесь .

Я смотрю на две вещи:

1) как загрузить мое приложение Service Fabric в контейнере .net в Docker Hub

Это похоже на этостатья при создании проекта SF Container вы можете указать расположение Docker Hub.Я создаю контейнер для существующего приложения .net и хочу использовать Docker Hub в качестве реестра.Могу ли я создать контейнер для аутсайдера SF и начать новый проект?

Я также буду вносить изменения в код (исправления ошибок, улучшения и т. Д.), И мне нужно будет загрузить эти изменения в мой образ, поэтому я предполагаю, что после установки Docker в качестве реестра в любое время, когда я его развертываюпомечать контейнер и загружать его в Docker Hub?

2) Как вытащить мой контейнер из Docker Hub для его развертывания в моем кластере сервисной фабрики onPrem.Я думаю, что это просто развертывание, как и любое другое приложение SF, но я хотел проверить.Есть ли еще какие-нибудь ошибки?

Спасибо,

Грег

ОБНОВЛЕНИЕ: Уточнение для @Diego Mendes

Я не пытаюсь развернутьSF «приложение», но как только вы добавляете Orchestration Support в существующее приложение .net, оно превращается в SF sln.Я создаю контейнер для существующего приложения .net 4.7, а затем собираю / внедряю этот контейнер.Я хочу использовать SF в качестве оркестратора.Кажется, если бы я использовал реестр Azure вместо Docker Hub, было бы намного проще управлять этим, поскольку вы можете легко публиковать данные в реестре Azure, но в Docker Hub нет опции публикации.Вопросы:

1a) Как лучше всего поместить этот контейнер в реестр Docker Hub?

Я думаю, что в худшем случае мне нужно будет загрузить изображение за пределыSF sln с помощью «Docker Push»?Затем я запускаю новый SF sln и использую шаблон контейнера для ссылки на местоположение Docker Hub при создании решения?Кажется немного странным.Тогда у меня будет два файла .sln, решение A, в котором размещается код и создается изображение.Затем опубликуйте это изображение в Docker Hub и используйте отдельное решение SF (решение B), в котором нет кода для управления контейнером?

1b) Как мне нужно обновить этот образ?

После того, как я загрузил свой образ контейнера в Docker-концентратор, а затем я делаю обновления кода, как загружать обновления.Это должно быть так же, как мы загружаем его на первое место.Если бы мне пришлось делать то, что я упомянул выше, я бы сохранил код в решении A и использовал решение B для организации изображения, созданного решением A?Я надеюсь, что это не способ сделать это, и я что-то упускаю.

ОБНОВЛЕНИЕ 2:

Я думаю, что мы на одной странице.Спасибо за все детали второй части вопроса.Суть моего вопроса лежит в первой части.

Я пытаюсь уточнить, сколько файлов решений мне нужно использовать.Нужно ли мне одно решение Visual Studio (решение A), которое компилирует мой код и создает образ, а затем отдельное решение Visual Studio (решение B) только для организации этого образа?Если это тот путь, по которому мне нужно идти, тогда последующий вопрос: должно ли Первым решением быть решение SF или я могу использовать любое Решение, создающее образ Docker.

Следующие шаги - загрузка вручную.в Docker Hub и посмотрите, что изменится в решении SF, когда я укажу на это в качестве источника моего контейнера.Может быть, я могу понять это и использовать только одно решение для создания и поддержки этого образа.

Answer 1

1) Вы не развертываете приложение Service Fabric в Docker Hub, вы развертываете образы контейнеров, не пытаетесь связать SF-приложение с процессом, просто думаете как обычный образ Docker.SF-приложение - это процесс, который происходит после.

Что касается управления версиями, попробуйте сравнить этот образ докера с неконтейнерным приложением, неконтейнерным приложением, которое вы бы создали на сервере CI (т. Е. VSTS).(Jenkins), а затем создайте исполняемое \ развертываемое приложение, которое может быть помещено, например, в zip-файл, и этот файл будет иметь имя, соответствующее версии, как правило, такое же, как сборка, сгенерировавшая его, образ докера будет иметь аналогичноепроцесс, но разница в том, что прежде чем поместить файлы в zip-файл, теперь вы сохраняете в формате изображения.

Каждое изображение будет иметь тег, который очень похож на версию, которую вы имели быдля неконтейнерного приложения, когда вы развертываете изображение, вы идентифицируете изображение по тегу, указанному при сборке изображения, а если вы не укажете одно, для него будет установлено последнее (чего следует избегать, я опишу, почемув обновлении ниже).

1a) Обновление

Я делаюЕсли вы не понимаете вашу озабоченность по поводу создания изображений, вы можете легко создать и опубликовать изображение в Docker Hub с помощью 3 простых команд (при условии, что у вас уже есть учетная запись реестра Docker):

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

Процесстак же, как вы делали бы с образом, отличным от SF, проверьте доки здесь , описывающие, как делать в реестре Docker без сервисной фабрики, и здесь как вы используете реестр Azure.

.

2) Вы делаете то же самое, что делаете в кластере Azure и в любом другом приложении SF, ссылка, которую вы предоставили, четко описывает это.

2a) Обновление

Чтобы обновить образы контейнера, вы должны изменить ServiceManifest.xml на тег новой версии образа вашего контейнера.

К сожалению,в документах не очень ясно, что в большинстве примеров используется неявный тег, который является последним, когда вы не определяете тег, он всегда будет считаться самым последним, а если изображение изменяется, он не распознаетэто потому, что тег один и тот же.

Вы всегда должны явно определять тег для своей службы, как в этом примере, V1 - это тег для 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>

Когда вы обновляете образ, вы добавляете в него новый тег, например V2, также обновляет версию ServiceManifest, чтобы показать SF, что пакет услуг изменился:

<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>

Относительно аутентификации для частногохранилище, вы добавляете его в ApplicationManifest.xml, в ServiceManifestImport:

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

Когда SF пытается загрузить изображение в хранилище, определенное в ServiceManifest.xml, оно будет использовать учетные данные, предоставленные в ApplicationManifest.xml для аутентификации в реестре.