Service Fabric - использовать Docker Hub As Registry Container (существующее приложение.net)
Это похоже, но отличается от того, что @emaia пыталась спросить здесь.
Я смотрю на две вещи:
1) как загрузить мое приложение Service Fabric в контейнере.net в Docker Hub
Похоже, на основе этой статьи при создании проекта SF Container вы можете указать расположение Docker Hub. Я создаю контейнер для существующего приложения.net и хочу использовать Docker Hub в качестве реестра. Могу ли я создать контейнер для аутсайдера SF и начать новый проект?
Я также буду вносить изменения в код (исправления ошибок, улучшения и т. Д.) И мне нужно будет загрузить эти изменения в мое изображение, поэтому я предполагаю, что после того, как я установил Docker в качестве своего реестра, каждый раз, когда я развертываю его, отмечаю контейнер и загружаю Докер-хаб?
2) Как вытащить мой контейнер из Docker Hub для развертывания в моем сервисном кластере onPrem. Я думаю, что это просто развертывание, как и любое другое приложение SF, но я хотел проверить. Есть ли еще какие-нибудь ошибки?
Спасибо,
Greg
ОБНОВЛЕНИЕ: Уточнение для @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, решение А, в котором размещается код и создается изображение. Затем опубликуйте этот образ в Docker Hub и используйте отдельное SF-решение (решение B), в котором нет кода для управления контейнером?
1b) Как мне сделать обновления для этого изображения?
После того, как я загрузил свой образ контейнера в Docker-концентратор, а затем я делаю обновления для кода, как загрузить обновления. Это должно быть так же, как мы загружаем его на первое место. Если бы мне пришлось делать то, что я упомянул выше, я бы сохранил код в решении A и использовал решение B для организации изображения, созданного решением A? Я надеюсь, что это не способ сделать это, и я что-то упускаю.
ОБНОВЛЕНИЕ 2:
Я думаю, что мы на одной странице. Спасибо за все детали по второй части вопроса. Суть моего вопроса лежит в первой части.
Я пытаюсь уточнить, сколько файлов решений мне нужно использовать. Нужно ли мне одно решение Visual Studio (решение A), которое компилирует мой код и создает образ, а затем отдельное решение Visual Studio (решение B) только для организации этого образа? Если по этому пути мне нужно идти, тогда последующий вопрос: должно ли Первым решением быть решение SF или я могу использовать любое Решение, создающее образ Docker.
Следующим шагом является ручная загрузка в Docker Hub и просмотр изменений, которые происходят в решении SF, когда я указываю на это как на источник моего контейнера. Может быть, я могу понять это и использовать только одно решение для создания и поддержания этого образа.
1 ответ
1) Вы не развертываете приложение сервисной фабрики в Docker Hub, вы развертываете образы контейнеров, не пытаетесь связать SF-приложение с процессом, просто думаете как обычный образ докера. Приложение 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, проверьте док-станции, описывающие, как это сделать в реестре докеров без сервисной фабрики, и здесь, как вы делаете это с помощью Azure Registry.
,
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 пройти аутентификацию в реестре.