I currently deploy the application to facilitate CI/CD processes. I'm in the process of identifying and setting it up.
I currently deploy the application to facilitate CI/CD processes. I'm in the process of identifying and setting it up.
The continuity screen is a valuable feature. What I initially attempted was deploying an application directly into the company's infrastructure, specifically using the agent mobility infrastructure. However, I've now shifted my approach to utilizing a deposit fee. This change will enable me to conduct operational CI/CD testing.
I haven't delved deep into the details, and I cannot add anything as of now, but they can improve their scalability.
I have been working with Azure Container Registry for some time.
It is stable. I would rate it an eight out of ten.
It is scalable. I would rate it an eight out of ten.
We used Azure Container Registry because I discussed it with AWS, and while it's developer-friendly, in my research, I've noticed that Azure seems to be the more prominent solution in the market. This preference is due to its cost-effectiveness and the familiarity many have with the platform.
The initial setup was straightforward. The deployment took one day.
I would rate the pricing a four out of ten.
I would rate it a nine out of ten.
The institution I work in intended to go with the Azure App Service with Docker containers, and Azure Container Registry fits the bill.
During the standard Azure DevOps pipeline, the institution built the container and then pushed the container directly to Azure Container Registry. Then, in the next stage of the same DevOps pipeline, the institution pulls the Docker image from the Azure App Service, which is already deployed to Azure Container Registry.
Overall, the Azure App Service posts the Docker images through its connection with the Azure Container Registry.
I'm working in a financial institution that has limitations to the type of service it can consume, even on the Azure cloud. There is a limited set of services, and Azure Container Registry is the only service approved by the security guy.
My main goal was to work independently from the container and the Azure App Service language that's already been predefined because when you deploy the application through the Azure App Service and you're working with REST API applications, there is a limited set of Java runtime compilers that can go and run on the Azure App Service, so the institution does not want to depend on the programming language from Microsoft. This is why the institution decided to go with containers, which is the only way forward.
With the Azure App Service and containers, Azure Container Registry is the only solution that can push and pull the Docker images because the configuration my institution has doesn't have access to the public internet, so my team cannot pull images randomly from different sources, even on-premise ones, so using Azure Container Registry is the only way the institution can inject images into the environment and resource groups.
What I like best about Azure Container Registry is the isolation feature from the boundaries of the infrastructure you are trying to deploy. You have Docker as a service that you can run and define. You can define different types of programming languages that you would like to use or a predefined version that's been approved by the security team. Azure Container Registry gives you better flexibility in your day-to-day work. The solution allows you to isolate standard containers, which is its most valuable feature.
I also like that Azure Container Registry gives you excellent information about what's happening. For example, you can look into what types of images you've gathered.
Azure Container Registry does what it's supposed to do and gives you visibility into the Docker images, the logs, information on pulling and pushing the data, etc.
From time to time, I've noticed some hiccups in Azure Container Registry. For example, the solution didn't work thrice, and the only solution Microsoft provided was to update Azure Container Registry. I've noticed that the IP address attached to the machine changed in the end.
The solution doesn't always work perfectly, so from time to time, you cannot pull or push the Docker images to the environment, which is an area for improvement. The only solution to this issue is to establish one more Azure Container Registry and attach the new IP address and DNS name to it.
The accessibility of Azure Container Registry also has room for improvement because the solution is not always accessible 24 x 7. I experienced this three times when the service wasn't responding, so I could not push or pull images, and I had to decommission Azure Container Registry and redeploy it. The only good thing is that I already have the infrastructure as a code, which makes it easier for me to set the solution up and create the environment from scratch. Still, the process will be annoying for people with manual operations around Azure Container Registry, mainly because the issue happens from time to time.
The only functionality I want to add to the service is the auto-scanning of images, which should tell me if there's any issue with the Docker images I need to address. The JFrog Artifactory has this functionality, but it would be an excellent feature to add to Azure Container Registry to scan the Docker images and check for possible vulnerabilities.
I've been using Azure Container Registry for seven months.
In the seven months of using Azure Container Registry, it didn't work three times, so stability-wise, it's a seven out of ten, but overall the service is good. Sometimes stability isn't the best.
Azure Container Registry is easy to scale. Whether you're going with the standard portal components or you'd like to use it through the infrastructure as a code, it doesn't take much time.
You have to click a button to scale up and use a different type of machine that supports the service, for example, and then you can switch from basic to premium operation. It's pretty easy. By default, though, if you go with the premium version, it's not easy to downgrade the infrastructure, which is typical for every cloud provider.
I have yet to contact the technical support for Azure Container Registry.
As mentioned previously, Azure Container Registry was the only solution approved by the security team. The institution has an on-premise solution, the JFrog Artifactory, where the binaries are kept and connected. Still, JFrog Artifactory doesn't have access to the Azure cloud, so the only solution was to compile applications and create Docker images during the CI pipeline, then push the images to the JFrog Artifactory, and then upload the same Docker images to Azure Container Registry, attached to the specific application. There's no other option to work with Docker containers in the environment apart from Azure Container Registry.
The initial setup for Azure Container Registry was pretty straightforward, especially when it's on an Azure environment. There's limited information you'll have to fill in, and then the service works straight away, so you won't have to set up complex elements to get Azure Container Registry up and running.
I'd rate the setup as ten out of ten because it's easy, even when you want to tune it up to disable public access, as I did. After all, by default, it's accessible to the public. If you want to set up private access on Azure Container Registry and remove the login and password token, it's easy to do. Even if you take one step forward by creating the same operation from the portal, it's made through the adjacent files, which is the Azure infrastructure as a code, so it's still relatively easy to set up.
Setting up Azure Container Registry took just one to two minutes.
My team deployed Azure Container Registry.
It's hard to say if there's ROI from Azure Container Registry because it nearly has the same functionality as the standard on-premise solution, such as JFrog Artifactory, which can support any application from the standard to Java to JavaScript elements, Docker images, etc. You need an additional service, in this case, Azure Container Registry, because of some limitations from the security team.
In this particular scenario, I don't see any specific value from Azure Container Registry, ROI-wise, because the JFrog Artifactory has the same functionality, sometimes even more, but because the connection is not allowed from an on-premise to the internal application infrastructure, then Azure Container Registry is the only option for my institution.
I have no information on how much Azure Container Registry costs. I know it's the only solution my institution can use, so the cost was approved.
My team has eleven members, all using Azure Container Registry. The institution I belong to has other users of Azure Container Registry. Still, it's hard to say how many because of the policy that every application should have its Azure Container Registry for security purposes.
My advice to any first-time user of Azure Container Registry or those looking to implement it is to build it as part of the infrastructure pipeline. When there is an issue with the service, it would be wise to auto-deploy it straight away instead of tweaking it from scratch because when you create Azure Container Registry from scratch, particularly when you set it up as not accessible to the public, every time you recreate it, you have to establish a dedicated connection and also set it up and keep the login password in the key vault, so there's some element of doing it manually, which is time-consuming. When there's some stability in Azure Container Registry, it's easier because you can trigger the pipeline, and it does everything you need after a few minutes versus spending one or two more days to set it up from scratch.
I'd rate Azure Container Registry as eight out of ten because it has many features required in a container registry, and the only missing part is image scanning for vulnerabilities. The service even allows you to disable public access, which is quite good because that's not always out of the box for other cloud providers. You already have the Webhooks in Azure Container Registry, which I'm trying to use. When there's a push or pull of information, you can inform other people or teams that there's a trigger, which is an excellent feature. Personally, the accessibility issue of Azure Container Registry, where the IP address is disabled, and you'd have to decommission and set the service up again, which affects stability, made me rate the service an eight rather than give it a perfect score.
My institution has a partnership with Azure Container Registry.
The solution is really useful because whenever you want to deploy the containers, you need to have a place to store those container codes so that they can deploy easily. It is always better to store those codes in the solution itself so that you can deploy them through the pipelines. That is where Azure Container Registry comes into the picture. And also, it can duplicate to different zones and locations.
The most valuable feature is the zone replication and resiliency, because otherwise you have to build a system, and you need to worry about the resiliency and the backup of those codes. With this solution, you don't have to worry about all those things.
The solution has become more popular in the last few years but I find that the technical support has not increased their knowledge base, so more knowledgeable support staff can help improve the solution.
I have been using the solution for three years.
The solution has built-in resiliency and replication zone availability so it is very stable.
The solution is scalable depending on the tier you select.
The initial setup is very straightforward with no hassle at all. The deployment takes about one hour.
The fees depend on the storage you are using. Azure Container Registry, has no cost, but you pay for storage service. So you pay based on the amount you store.
I give the solution a seven out of ten.
We have at least two clients that use this solution.
There are a lot of ways to store your codes. You can obviously use your deployment tool, or the code repository to store the code like your GitHub or Azure DevOps. But when it comes to the Container Registry, it is better to store your container codes in Azure Container Registry itself, because it has a lot of advantages over a normal Git repository.
We use the solution for image processing. We store and manage images. You can utilize the tools to recognize and organize images. For example, you have an image and gather two more images, each with different versions and tagging system. You should filter different variations of these images. Based on the algorithm, you can generate multiple images and then deploy them using Docker for testing or in AKS. We should know how to create and tag the image as part of microservices.
You can access the Azure Container Registry and store container images. You can also see the versioning history and other details about your images.
The solution could provide more integration.
I have been using Azure Container Registry for three years.
The GUI and interface are good, and we can navigate easily, but it has the typical Azure interface.
I rate the solution’s stability an eight out of ten.
You can buy a license and set up another Azure Container Registry when you want to have a more image repository.
We deploy to AKS as a service. Once deployed, people generally access Kubernetes indirectly through ACR. People don't directly access ACR. There is no problem with multiple users accessing ACR.
We have 1000 users using this solution.
The initial setup is straightforward. You should create an ACR and then configure communication between ACR and ACS.
Deployment takes a maximum of five minutes to push to ACR. Once the docker build is running and the Docker file is fine. Then, you must go to the login page here and put the image.
We have a one-year or two-year contract. We can extend it to a ten-year contract because it is a stable application. We have our images ready, with which we want to focus on the customer. We are using and maintaining them. ACR even supports some kind of complex work.
For this application, we have a team of technical people who are very available and are working on the application. We have two technical engineers. We currently don't have multiple capabilities, but we have already trained the team on ACR and Docker and are training some of them on AKS. They are now building applications.
Overall, I rate the solution a seven out of ten.
Our primary use case for the solution is storing Docker images on Azure Container Registry, and we deploy it on cloud.
The solution has helped minimize time by ensuring there is no vulnerability. If there is any vulnerability in the Docker image, the build fails and does not allow it to deploy to a production environment.
The scanning of Docker images is the most valuable feature.
It's not an open source, and we pay per hour to Microsoft Azure.
We have been using the solution for six months.
The solution is stable. I rate it as eight out of ten.
The solution is scalable, and ten users currently utilize it in our organization. I rate the scalability as eight out of ten.
The initial setup is straightforward, and you have to take the service directly from Microsoft Azure Service from Azure Portal. A third party completed the deployment.
I rate the solution as eight out of ten. Regarding advice, if you create an account in Azure Portal, there is a $200 free credit for the new user, and they can use this $200 free credit and practice an ACRA case later.
It's a container repository. It's like a Docker hub. With it, you can post the image of the container right there.
We can use these images in an ECR on Kubernetes, which has been quite useful to the organization.
It's great for storing images on containers.
The solution has no areas that need improvement.
I've been using the solution for five years. I've used the product for a while at this point. It's been many years.
I'd rate the stability zero out of ten.
I'd rate the scalability zero out of ten.
Technical support has been very helpful and responsive.
Positive
We have witnessed an ROI while using the solution.
There isn't a specific version associated with the product.
I'd advise potential users to just give it a try.
I'd rate the solution five out of ten.
I'm a cloud infrastructure consultant and we have a partnership with Azure.
We use ACR as a registry to store images and these images can be pulled by k8s do deploy applications
I like that the solution has encryption and can make use of access keys for security, what they call panic identity. The feature provides secure duplication and also provides the option for service webhooks - it's very useful. Container Registry is a good, private platform. The quick start option gives a step-by-step guide on how to move images to and from your containers. The solution is user-friendly and there's plenty of documentation to help guide you through. It's great that images can be deployed from the Container Registry direct to an Azure Web application. From inside the Container Registry repositories, you can deploy images directly to a fresh web app. It reduces redundancy and the stress of leaving the current page of the Container Registry and going to a web app container to create a new web app. It can be done from the container registries dialogue space which I like. Replications is a very nice feature, although it requires you to upgrade to a premium SKU.
I don't have many issues with the solution but I would like it if the access keys could be stored in a master key vault. If they could be hashed and the value of that hash stored in the key vault so that it's not visible on the portal, would be a helpful addition.
I've been using this solution for a year.
The solution is stable.
I haven't yet needed to scale significantly. I currently have about 8 repositories on the Container Registry and haven't had any problems. I think it's a scalable product.
All the steps involved with this product have been quite easy for me to deal with and I've never needed to make contact with customer service.
Positive
The initial setup is very easy. I deploy for clients so it was easy for me to implement it within our organization.
Pricing is flexible; you can choose the basic, standard, or a premium license based on your needs. I think it's quite flexible because you can choose the option that falls within your budget.
I rate this solution nine out of 10.
We use Azure Container Registry to store our container images and the solution that we build for automation.
Azure Container Registry is an easy-to-install, easy-to-configure, and easy-to-deploy solution. The solution requires minimal overhead. To manage our own Azure Container Registry, we go to Azure, create a registry for us, and start publishing the images.
The way Azure RBAC is configured, our oldest access control, allows us to leverage that so that no one can push it, and we can use it in our solution. I used Azure Container Registry with my Azure Batch job to run the tagging solution.
I have been using Azure Container Registry for six months.
I rate Azure Container Registry ten out of ten for stability.
It is good enough to store all the images we need, and we can create as many container registries as we need.
I rate Azure Container Registry ten out of ten for scalability.
The solution's initial setup is easy. On a scale from one to ten, where one is easy and ten is difficult, I rate the solution a one out of ten for the ease of its initial setup.
You need to know how containers and docker images work when interacting with and installing Azure Container Registry.
Azure Container Registry can be deployed within two to three minutes.
I would recommend Azure Container Registry to other users because it has good security features.
Overall, I rate Azure Container Registry a nine out of ten.
