Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

ProGet - support for running on Azure Kubernetes Cluster?



  • Hello,

    For the last few years we've been happily running a Free instance of ProGet on an Azure Windows virtual machine.

    We're looking to upgrade to a Basic license early in the new year to unlock some of the additional features, and as part of that we'd like to migrate to running as a container on an Azure Kubernetes Cluster instead of a Windows vm.

    Looking at other tickets in this forum, some of your customers are already doing that but I wanted to check what the official line is from your support team? We have a number of people in-house who administer and maintain the base cluster, but we want to make sure we stay on the official ProGet support matrix as well.

    Could you confirm whether running the ProGet image on a Kubernetes cluster is a supported configuration? Or is support only available for Docker-based containers?

    Thanks,

    Mike


  • inedo-engineer

    Hi @mike_5084 ,

    Note that running ProGet as a server cluster will require a ProGet Enterprise license. So I think you may want to use Azure Container Services? That's usually what we see most ProGet Basic users use on Azure (aside from a VM).

    Under the hood, Azure Kubernetes/Container Services uses Docker. We support ProGet running on Docker, and have some instructions which you've certainly seen:
    https://docs.inedo.com/docs/installation-linux-docker-guide

    However, we don't support Azure directly, as we're not familiar enough with Azure to advise what Azure-specific commands are required, how to troubleshot Azure-errors, what networking configuration is required on Azure, etc.

    Contrast this with Windows, where we can typically advise on how to do nearly all Windows admin/troubleshooting things, from managing the Windows certificate store to changing service configuration using sc.exe, etc.

    That being said, if you can "translate" our documentation to Azure, and are comfortable setting it all up, then you should be fine.

    Alana



  • Hi @atripp - thanks for the reply - I've only just seen this after the Christmas holidays :-)

    Just to clarify, we only plan to run a single instance of a ProGet container but it'll be running on an AKS instance - the "cluster" I was referring to is the underlying Kubernetes platform as opposed to, say, a cluster of HA ProGet server containers, so I think the Basic edition should be fine.

    I understand what you're saying about supporting your product vs supporting the infrastructure it runs on - we've got in-house SMEs for Kubernetes and Azure so we can support the infrastructure ourselves and it sounds like you're prepared to provide product support for containerised instances running in Azure / AKS. For a contrived example let's say we're having problems with AD integration - if you're able to help troubleshoot error messages and identify that ProGet is unable to talk to a domain controller we'd certainly be capable of investigating the underlying Azure / AKS configuration ourselves for issues with, e.g. vnets, subnets, nsgs, etc.

    I'm going to try to spin up a PoC using a trial license over the next week or so, and if that meets our requirements (I'm assuming it will from your documentation) then I expect our procurement / service delivery guys will be in touch to get a formal statement re support, but I'll leave that to them to organise :-).

    Thanks again,

    Mike


  • inedo-engineer

    Sounds like a plan :)

    Let us know if we can help , or if you run into any issues!



  • Will do - happy to be a guinea pig :-)

    I've found one small hiccup already I think - our Azure Active Directory instance has enforced MFA on accounts, so I won't be able to use Windows Authentication for ProGet to connect to SQL Server and I've been advised to use a Service Principal instead, but System.Data.SqlClient doesn't support authenticating to SQL Server with a service principal:

    # build the connection string
    PS C:\temp> $connectionString = ([ordered] @{
        "Server"         = "my-sql-server.database.windows.net"
        "Authentication" = "Active Directory Service Principal"
        "Encrypt"        = "True"
        "Database"       = "my-sql-database"
        "User Id"        = "00000000-0000-0000-00000000000"
        "Password"       = "<secret-generated-by-azure>"
    }).GetEnumerator() | foreach-object { $_.Name + "=" + $_.Value } | join-string -Separator ";"
    
    # show the connection string
    PS C:\temp> $connectionString
    Server=my-azure-database.database.windows.net;Authentication=Active Directory Service Principal;Encrypt=True;Database=my-proget-database;User Id=00000000-0000-0000-0000-000000000000;Password=<secret-generated-by-azure>
    
    PS C:\temp>.\inedosql.exe update . --connection-string=$connectionString
    
    Unhandled Exception: System.ArgumentException: Invalid value for key 'authentication'.
       at System.Data.Common.DbConnectionStringBuilderUtil.ConvertToAuthenticationType(String keyword, Object value)
       at System.Data.SqlClient.SqlConnectionString.ConvertValueToAuthenticationType()
       at System.Data.SqlClient.SqlConnectionString..ctor(String connectionString)
       at System.Data.SqlClient.SqlConnectionFactory.CreateConnectionOptions(String connectionString, DbConnectionOptions previous)
       at System.Data.ProviderBase.DbConnectionFactory.GetConnectionPoolGroup(DbConnectionPoolKey key, DbConnectionPoolGroupOptions poolOptions, DbConnectionOptions& userConnectionOptions)
       at System.Data.SqlClient.SqlConnection.ConnectionString_Set(DbConnectionPoolKey key)
       at System.Data.SqlClient.SqlConnection.set_ConnectionString(String value)
       at System.Data.SqlClient.SqlConnection..ctor(String connectionString, SqlCredential credential)
       at Inedo.DbUpdater.SqlServer.SqlServerDatabaseConnection.GetConnection()
       at Inedo.DbUpdater.SqlServer.SqlServerDatabaseConnection.ExecuteTable[TResult](String query, Func`2 adapter, SqlTransactiontransaction, SqlParameter[] args)
       at Inedo.DbUpdater.SqlServer.SqlServerDatabaseConnection.GetChangeScriptVersion(SqlTransaction transaction)
       at Inedo.DbUpdater.SqlServer.SqlServerDatabaseConnection.GetState()
       at Inedo.DbUpdater.Program.Update(String scriptPath, String connectionString, Boolean force)
       at Inedo.DbUpdater.Program.Run(ArgList args)
       at Inedo.DbUpdater.Program.Main(String[] args)
    

    See System.ArgumentException: Invalid value for key 'authentication' above.

    The answer is apparently to migrate to the Microsoft.Data.SqlClient package which supports additional Azure-based authentication methods - that's obviously quite a big change though but I figured I'd mention it so you were aware...

    See https://learn.microsoft.com/en-us/sql/connect/ado-net/sql/azure-active-directory-authentication?view=sql-server-ver16#using-service-principal-authentication for more details.

    Here's the equivalent login from SQL Server Management Studio, which works with the credentials I've put in my connection string above:

    1b0f3856-c0d0-4421-8092-95804daff626-image.png

    In the meantime I'll follow up with our secops team to see if I can get an exemption from the MFA policy for a new Azure AD account...


Log in to reply
 

Inedo Website HomeSupport HomeCode of ConductForums GuideDocumentation