Skip to content

Add Dockerfile port detection to ingress configuration logic#449

Merged
MicroFish91 merged 29 commits intomainfrom
mwf/deployWorkspaceProject-III
Sep 15, 2023
Merged

Add Dockerfile port detection to ingress configuration logic#449
MicroFish91 merged 29 commits intomainfrom
mwf/deployWorkspaceProject-III

Conversation

@MicroFish91
Copy link
Copy Markdown
Contributor

@MicroFish91 MicroFish91 commented Sep 11, 2023

Related to: #425

Added a pre-configuration path for ingress when a Dockerfile is detected + tests

@MicroFish91 MicroFish91 force-pushed the mwf/deployWorkspaceProject-III branch from 1da4d49 to 57e86fe Compare September 11, 2023 22:42
@MicroFish91 MicroFish91 marked this pull request as ready for review September 11, 2023 22:50
@MicroFish91 MicroFish91 requested a review from a team as a code owner September 11, 2023 22:50
context.targetPort = getDefaultPort(context);
}

// If a container app already exists, activity children will be added automatically in later execute steps
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will add this back in once we add all the activity children support in upcoming PR


const portRanges: PortRange[] = [];
for (const line of lines) {
if (/^EXPOSE/i.test(line.trim())) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dockerfiles aren't too tough to parse, but it may be easier to use an existing parser. The Dockerfile language service used by the Docker extension has one. https://www.npmjs.com/package/dockerfile-ast

Copy link
Copy Markdown
Contributor Author

@MicroFish91 MicroFish91 Sep 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I did look into this one a little bit before and I ended up feeling unsure if it removed enough complexity to warrant adding a third party dependency since the scope of use is relatively small here.

From what I can tell, I would still have to loop through each line in search of an expose keyword (fairly similar to what I'm doing already). Also the parsed args list it provides is still made up of raw strings that I have to loop through again to identify ranges - and slashes / so that I can convert them into useable port numbers/ranges.

I think the main benefit I see is that it might reduce the complexity of some of the RegExp that I'm using, but the overall process doesn't seem to get that much simpler. With this context, do you think it would still be beneficial to use the new dep?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair, I think it's fine to manually parse, just make sure you know all the variations that an EXPOSE statement can have.

@MicroFish91 MicroFish91 force-pushed the mwf/deployWorkspaceProject-III branch from 6786c9c to a721f97 Compare September 12, 2023 21:20
}
}

export async function getDockerfileExposePorts(dockerfilePath: string): Promise<PortRange[] | undefined> {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should call this tryGetDockerfileExposePorts since it can return undefined.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also feels like that this should just be in its own file.

@@ -0,0 +1,7 @@
## Modified example from Azure-Samples/acr-build-helloworld-node
FROM node:15-alpine
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that it probably doesn't matter for our unit tests, but should we try to target things other than node:15-alpine?

Copy link
Copy Markdown
Contributor Author

@MicroFish91 MicroFish91 Sep 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair, I literally just copy pasted everything from the original azure-sample and just changed the expose sections


import type { PortRange } from "../../extension.bundle";

export interface MockIngressContext {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just want to confirm, but the reason you're not just using the IngressContext because of the containerApp has too many required properties that aren't worth mocking?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's a big part of the reason

for (const [i, ds] of dockerfileSamples.entries()) {
const context: MockIngressContext = {
dockerfilePath: i === 1 ? undefined : ds.fsPath,
alwaysPromptIngress: i === 3
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that you're only setting this true for the 4th dockerfile? Maybe add a comment in the expected results which one has this true?

I'm not sure how to do it better, but I think it would be kind of difficult to add tests to this suite if we ever do. Definitely not worth blocking, but I'll keep thinking about it as well.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have it in the expected results array at the top!

Copy link
Copy Markdown
Contributor Author

@MicroFish91 MicroFish91 Sep 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add the =true modifier


context.dockerfileExposePorts = await getDockerfileExposePorts(context.dockerfilePath);

if (context.alwaysPromptIngress) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small nit, but should probably be at the top of the file so we don't waste any time doing the async call above.

Copy link
Copy Markdown
Contributor Author

@MicroFish91 MicroFish91 Sep 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This position is intentional, because it's still nice to grab the expose ports so we can provide port suggestions later down the line (results can be leveraged when we call getDefaultPort again later)

@MicroFish91 MicroFish91 force-pushed the mwf/deployWorkspaceProject-III branch from 6ca6925 to de11fc0 Compare September 13, 2023 19:44
Base automatically changed from mwf/deployWorkspaceProject-II to main September 15, 2023 18:53
@MicroFish91 MicroFish91 merged commit d28f31b into main Sep 15, 2023
@MicroFish91 MicroFish91 deleted the mwf/deployWorkspaceProject-III branch September 15, 2023 19:04
@microsoft microsoft locked and limited conversation to collaborators Mar 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants