Can I stop Azure Container Service for Linux from issuing Docker Pull commands?












0














I am using an Azure App Service (Linux containers) to host a container application. Unfortunately for me, the App Service periodically issues a new Docker Pull command like this:



2018-11-08 18:39:32.512 INFO  - Issuing docker pull: imagename =library/ghost:2.2.4-alpine


I don't know why it is issuing this command, and I can't find out how to stop it doing so.



I want to stop it because although the volume on which my container stores data can survive restarts of the container, it doesn't seem to survive rebuilding the container. I suspect that this might be because I'm using the Docker Compose (preview), and the docker compose configuration sets a volume name and associates it with the container.



I currently have 'continuous deployment' toggled 'OFF' in the azure console, and I can't find any setting which seems to control whether or not the underlying app service is issuing the docker pull command.



Unfortunately I can't use the docker single container as the pre-built ghost images don't appear to be set up to store data in a volume outside the container.



I have had no luck in searching the App Service FAQs for information about this behaviour. I'm hoping that I've made a foolish mistake which is easy to fix, and that someone here will have seen this and fixed it themselves.










share|improve this question






















  • is it possible the service is crashing and that's when the pull occurs?
    – Devis Lucato
    Nov 9 '18 at 7:34










  • I don't think that is possible - the service was working perfectly right up to the moment when the app service issued the docker pull request. Nothing in any logs I could find that suggested a problem before that either.
    – Alex White
    Nov 9 '18 at 9:35
















0














I am using an Azure App Service (Linux containers) to host a container application. Unfortunately for me, the App Service periodically issues a new Docker Pull command like this:



2018-11-08 18:39:32.512 INFO  - Issuing docker pull: imagename =library/ghost:2.2.4-alpine


I don't know why it is issuing this command, and I can't find out how to stop it doing so.



I want to stop it because although the volume on which my container stores data can survive restarts of the container, it doesn't seem to survive rebuilding the container. I suspect that this might be because I'm using the Docker Compose (preview), and the docker compose configuration sets a volume name and associates it with the container.



I currently have 'continuous deployment' toggled 'OFF' in the azure console, and I can't find any setting which seems to control whether or not the underlying app service is issuing the docker pull command.



Unfortunately I can't use the docker single container as the pre-built ghost images don't appear to be set up to store data in a volume outside the container.



I have had no luck in searching the App Service FAQs for information about this behaviour. I'm hoping that I've made a foolish mistake which is easy to fix, and that someone here will have seen this and fixed it themselves.










share|improve this question






















  • is it possible the service is crashing and that's when the pull occurs?
    – Devis Lucato
    Nov 9 '18 at 7:34










  • I don't think that is possible - the service was working perfectly right up to the moment when the app service issued the docker pull request. Nothing in any logs I could find that suggested a problem before that either.
    – Alex White
    Nov 9 '18 at 9:35














0












0








0







I am using an Azure App Service (Linux containers) to host a container application. Unfortunately for me, the App Service periodically issues a new Docker Pull command like this:



2018-11-08 18:39:32.512 INFO  - Issuing docker pull: imagename =library/ghost:2.2.4-alpine


I don't know why it is issuing this command, and I can't find out how to stop it doing so.



I want to stop it because although the volume on which my container stores data can survive restarts of the container, it doesn't seem to survive rebuilding the container. I suspect that this might be because I'm using the Docker Compose (preview), and the docker compose configuration sets a volume name and associates it with the container.



I currently have 'continuous deployment' toggled 'OFF' in the azure console, and I can't find any setting which seems to control whether or not the underlying app service is issuing the docker pull command.



Unfortunately I can't use the docker single container as the pre-built ghost images don't appear to be set up to store data in a volume outside the container.



I have had no luck in searching the App Service FAQs for information about this behaviour. I'm hoping that I've made a foolish mistake which is easy to fix, and that someone here will have seen this and fixed it themselves.










share|improve this question













I am using an Azure App Service (Linux containers) to host a container application. Unfortunately for me, the App Service periodically issues a new Docker Pull command like this:



2018-11-08 18:39:32.512 INFO  - Issuing docker pull: imagename =library/ghost:2.2.4-alpine


I don't know why it is issuing this command, and I can't find out how to stop it doing so.



I want to stop it because although the volume on which my container stores data can survive restarts of the container, it doesn't seem to survive rebuilding the container. I suspect that this might be because I'm using the Docker Compose (preview), and the docker compose configuration sets a volume name and associates it with the container.



I currently have 'continuous deployment' toggled 'OFF' in the azure console, and I can't find any setting which seems to control whether or not the underlying app service is issuing the docker pull command.



Unfortunately I can't use the docker single container as the pre-built ghost images don't appear to be set up to store data in a volume outside the container.



I have had no luck in searching the App Service FAQs for information about this behaviour. I'm hoping that I've made a foolish mistake which is easy to fix, and that someone here will have seen this and fixed it themselves.







docker-compose azure-web-app-service






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 8 '18 at 19:49









Alex White

9621020




9621020












  • is it possible the service is crashing and that's when the pull occurs?
    – Devis Lucato
    Nov 9 '18 at 7:34










  • I don't think that is possible - the service was working perfectly right up to the moment when the app service issued the docker pull request. Nothing in any logs I could find that suggested a problem before that either.
    – Alex White
    Nov 9 '18 at 9:35


















  • is it possible the service is crashing and that's when the pull occurs?
    – Devis Lucato
    Nov 9 '18 at 7:34










  • I don't think that is possible - the service was working perfectly right up to the moment when the app service issued the docker pull request. Nothing in any logs I could find that suggested a problem before that either.
    – Alex White
    Nov 9 '18 at 9:35
















is it possible the service is crashing and that's when the pull occurs?
– Devis Lucato
Nov 9 '18 at 7:34




is it possible the service is crashing and that's when the pull occurs?
– Devis Lucato
Nov 9 '18 at 7:34












I don't think that is possible - the service was working perfectly right up to the moment when the app service issued the docker pull request. Nothing in any logs I could find that suggested a problem before that either.
– Alex White
Nov 9 '18 at 9:35




I don't think that is possible - the service was working perfectly right up to the moment when the app service issued the docker pull request. Nothing in any logs I could find that suggested a problem before that either.
– Alex White
Nov 9 '18 at 9:35












1 Answer
1






active

oldest

votes


















1














For your issue, you will know how to achieve what you want if you know the work process of Azure Web App for Container.



Each time when the Web App starts, no matter you restart it or restart itself because of the timeout, it will check the image if it should update. When you use the public Docker hub image, the update dependent on the Docker hub, not your order.



So the best way for you is to store the image in your private container registries like your own git hub or Azure Container Registry. And give the image a specific tag. This way make sure that if you do not update the image, the web app will do the check when it starts.






share|improve this answer





















  • Thanks Charles - I'll get onto a private azure container registry right away! (I had foolishly assumed that the docker container I was using was using semantic versioning, and wouldn't be updated with that particular version number. How wrong I was etc etc!
    – Alex White
    Nov 18 '18 at 21:16










  • Nobody can do everything right, so we always have the chance to do the right thing and good luck!
    – Charles Xu
    Nov 19 '18 at 1:10











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53215135%2fcan-i-stop-azure-container-service-for-linux-from-issuing-docker-pull-commands%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














For your issue, you will know how to achieve what you want if you know the work process of Azure Web App for Container.



Each time when the Web App starts, no matter you restart it or restart itself because of the timeout, it will check the image if it should update. When you use the public Docker hub image, the update dependent on the Docker hub, not your order.



So the best way for you is to store the image in your private container registries like your own git hub or Azure Container Registry. And give the image a specific tag. This way make sure that if you do not update the image, the web app will do the check when it starts.






share|improve this answer





















  • Thanks Charles - I'll get onto a private azure container registry right away! (I had foolishly assumed that the docker container I was using was using semantic versioning, and wouldn't be updated with that particular version number. How wrong I was etc etc!
    – Alex White
    Nov 18 '18 at 21:16










  • Nobody can do everything right, so we always have the chance to do the right thing and good luck!
    – Charles Xu
    Nov 19 '18 at 1:10
















1














For your issue, you will know how to achieve what you want if you know the work process of Azure Web App for Container.



Each time when the Web App starts, no matter you restart it or restart itself because of the timeout, it will check the image if it should update. When you use the public Docker hub image, the update dependent on the Docker hub, not your order.



So the best way for you is to store the image in your private container registries like your own git hub or Azure Container Registry. And give the image a specific tag. This way make sure that if you do not update the image, the web app will do the check when it starts.






share|improve this answer





















  • Thanks Charles - I'll get onto a private azure container registry right away! (I had foolishly assumed that the docker container I was using was using semantic versioning, and wouldn't be updated with that particular version number. How wrong I was etc etc!
    – Alex White
    Nov 18 '18 at 21:16










  • Nobody can do everything right, so we always have the chance to do the right thing and good luck!
    – Charles Xu
    Nov 19 '18 at 1:10














1












1








1






For your issue, you will know how to achieve what you want if you know the work process of Azure Web App for Container.



Each time when the Web App starts, no matter you restart it or restart itself because of the timeout, it will check the image if it should update. When you use the public Docker hub image, the update dependent on the Docker hub, not your order.



So the best way for you is to store the image in your private container registries like your own git hub or Azure Container Registry. And give the image a specific tag. This way make sure that if you do not update the image, the web app will do the check when it starts.






share|improve this answer












For your issue, you will know how to achieve what you want if you know the work process of Azure Web App for Container.



Each time when the Web App starts, no matter you restart it or restart itself because of the timeout, it will check the image if it should update. When you use the public Docker hub image, the update dependent on the Docker hub, not your order.



So the best way for you is to store the image in your private container registries like your own git hub or Azure Container Registry. And give the image a specific tag. This way make sure that if you do not update the image, the web app will do the check when it starts.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 13 '18 at 6:10









Charles Xu

3,371127




3,371127












  • Thanks Charles - I'll get onto a private azure container registry right away! (I had foolishly assumed that the docker container I was using was using semantic versioning, and wouldn't be updated with that particular version number. How wrong I was etc etc!
    – Alex White
    Nov 18 '18 at 21:16










  • Nobody can do everything right, so we always have the chance to do the right thing and good luck!
    – Charles Xu
    Nov 19 '18 at 1:10


















  • Thanks Charles - I'll get onto a private azure container registry right away! (I had foolishly assumed that the docker container I was using was using semantic versioning, and wouldn't be updated with that particular version number. How wrong I was etc etc!
    – Alex White
    Nov 18 '18 at 21:16










  • Nobody can do everything right, so we always have the chance to do the right thing and good luck!
    – Charles Xu
    Nov 19 '18 at 1:10
















Thanks Charles - I'll get onto a private azure container registry right away! (I had foolishly assumed that the docker container I was using was using semantic versioning, and wouldn't be updated with that particular version number. How wrong I was etc etc!
– Alex White
Nov 18 '18 at 21:16




Thanks Charles - I'll get onto a private azure container registry right away! (I had foolishly assumed that the docker container I was using was using semantic versioning, and wouldn't be updated with that particular version number. How wrong I was etc etc!
– Alex White
Nov 18 '18 at 21:16












Nobody can do everything right, so we always have the chance to do the right thing and good luck!
– Charles Xu
Nov 19 '18 at 1:10




Nobody can do everything right, so we always have the chance to do the right thing and good luck!
– Charles Xu
Nov 19 '18 at 1:10


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53215135%2fcan-i-stop-azure-container-service-for-linux-from-issuing-docker-pull-commands%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Bressuire

Vorschmack

Quarantine